This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Requesting User Input: Proposal for Changing Part Rendering In AECOsim Building Designer

We are currently considering making a change to how the family/part system handles rendering material in AECOsim Building Designer and would like to solicit input and feedback from our users on this proposal.

 Current State- 

AECOsim Building Designer’s Part Rendering is based on a reference look-up system, meaning that when an element goes to be rendered it queries the part system to provide the name of the rendering material to apply at render time. The only thing attached to the element is the part reference. This allows users to have one degree of separation between the element and the rendering material, permitting the user to change the rendering material at the part level. Changes at the part level would instantly present the new rendering material during the next rendering request.

What is being proposed- 

The proposal is separate the part assignment and the rendering material assignment.  The placement methodology of elements with the part assignment does not change, however when an element is place, besides getting the part assignment the element would receive an attribute for the rendering material. Therefore, it would no longer rely on the part definition to supply the rendering material. This rendering material attribute is the same rendering material attachment methodology used for MicroStation Rendering. User will still be able to achieve that one degree of separation; however this is achieved by physically altering the rendering material definition vs swapping one named render material definition for another, also providing the immediate results at the next rendering request.  When a rendering material is attached as an attribute, this setting overrides the assignments by level and color, just like in MicroStation. Attached rendering materials also are saved with the model as local materials.  For element cuts or sections, we will still defer to the Family/Part cut definition as it is currently more mature than the rendering materials cut definition and provides time tested results for documentation. 

So, what is the catalyst for this proposal-

With the inclusion of Luxology Rendering Engine into the Bentley product line, our rendering capabilities continually and incrementally are advancing. MicroStation has very well established rendering workflow and on occasion the Part and Family rendering system has either conflicted with the MicroStation methodology or lagged behind in the adoption of the visualization advancements. It is with these reason in mind, we are considering consolidate our part rendering to comply with MicroStation material association methods.

 What do we see as some of the potential Pro’s and Con’s-               

Anticipated PROS:

  • AECOsim Building Designer’s load time would decrease for opening a file.
  • Rendering performance will improve, closing the gap to native MicroStation.
  • Users can render without AECOsim Building Designer being loaded or access to the dataset. (Excludes unification)
  • Consolidate visualization workflows and behavior between MicroStation and AECOsim Building Designer
  • Would permit offsets and rotation of geometry maps for pattern alignment
  • Allow AECOsim Building Designer to quickly adopt Vizualization enhancements and maintain alignment with MicroStation

Anticipated  CONS

  • Part Reference look-up allowed for easy change material assignment, changing material assignment to new rendering material requires every element to be touched.  User will need to adopt the MicroStation visualization workflow.

Anticipated  considerations:

  • AECOsim Building Designer will have to provide an upgrade tool, to allow visualations to migrate visualation forward to accomodate this proposed change
  • AECOsim Building Designer can create a new utility as part of Verify Parts that will assist the  re-synchronizes active settings (level, weight color, style, rendering material) with current part definition) 

Please vote below and any addition comments, feedback or reservations welcome.

  • Unknown said:
    AECOsim Building Designer can create a new utility as part of Verify Parts that will assist the  re-synchronizes active settings (level, weight color, style, rendering material) with current part definition) 

    OK. But the platform Mstn material assignment tool should be able to read the elements part info and assign / attach materials based on the Part assignment independently of BBD. The visualisation guy should be able to select by Part and assign/attach materials based on that attribute info, with or without without BBD.

    Unknown said:
    Users can render without AECOsim Building Designer being loaded or access to the dataset. (Excludes unification)

    Unification should be available outside BBD for rendering purposes. Suppress joint lines based on tolerances?

    Unknown said:
     For element cuts or sections, we will still defer to the Family/Part cut definition as it is currently more mature than the rendering materials cut definition and provides time tested results for documentation. 

    What about using Element Templates? ET's can already be used to define hatches for cross section profiles. What does F+P do that the rendering set up can't... at the moment?

    Not sure how Luxo would develop, but shouldn't it be based on ET's at platform level?

  • Ooh pipped to the post....

    I agree that something needs to be done to make working in different packages a little more consistent.

    Material assignments must be consistent across a project files. Parts&Families do this, but are not available to edit in vanilla MicroStation. Element Templates are available, and do a very similar job of controlling symbology. So similar, I propose that Parts&Families should be changed, so thier function is merely to concatenate, filter and regroup individual Element Templates for use in on-the-fly per element (& per scale &/or themeatic) Rendering/Forward/Back/Cut styles in Dynamic Views.

    Element templates should be able to override (like levels do)  incoming reference info, so that geometric info from a consultant can be used directly in your own extractions.

    Element Template assignments should also carry origin and orientation (projection mapping) information for each assignment as a matter of course.

    Having unification as a MicroStation function makes sense too.

  • Unknown said:
    so thier function is merely to concatenate, filter and regroup individual Element Templates

    Sure. But, the tools for this should be provided at Platform level. They would read and sort F+P info, or GIS Desktop features, or Civils features or IFC attributes or Plant items ECX attributes or stuff coming in via DWG or FBX or Modo or Maxwell..... and assign/attach the materials info based on how the user wants to sort things. It's all just more info.

    Civils are an indicative use case: The main way of defining symbology is through the verticals' feature info, but they also allow the feature info to be overriden by ET's in order to cater to all those inevitable special requirements, which would otherwise mean a duplication of data just to get another representation/print.

    Hopefully, ET's will provide concatenating, filtering etc by using/managing multiple dgnlibs?

    Unknown said:
    Element Template assignments should also carry origin and orientation (projection mapping) information for each assignment as a matter of course.

    Not sure. It may be better if ET's would just reference projections defined elsewhere. Multiple elements would be free to reference a single projection... so the stacked wall example would all ref a projection defined at the bottom-most wall, say. If the projection is not defined, then the projection would default to whatever.... you choose.

    I think the definition tool needs to have a lot of flexibility, and be scripting-capable. Maybe, something like Modo's ShaderTree interface would be a good starting point. The intelligence would be in the tool. The elements would only keep the minimum amount of info.

  • Parts&Families would only be the automatic switching tool AECOSim uses to push out a particular set of Element Templates for manual editing/refitting in MicroStation during an extraction/DV. If someone wanted to draft and assign ETs manually the end effect would be the same... at least for production documents. Not sure how datagroup info et al would cope, but the I guess if you are doing BIM use a BIM tool.

    As for the projection assignment what I mean is that it should be plain to see and to manipulate from the moment the part is assigned, including whether it defaults to a global rule or needs to be added a group. This.is.important because forward cell mapping is.responsible for how.drawing elevations turn out.

    I agree about the flexibility requirements. I see families being used as the assignment (eg BrickWork, DoorFrame, etc) and parts being the flexible mix and match playbook for picking ETs (dark outline with horizontal hatching) for that family for a task (elevational forward view at 1:100)

  • Unknown said:
    Parts&Families would only be the automatic switching tool AECOSim uses to push out a particular set of Element Templates

    I think it would be better to look at things from a 'pull' perspective. BBD is not Bentley's viz tool. Mstn/Luxo is, at the moment. I see ET's as an intermediate or 'first pass' definition for rendering. A visualiser would get models from multiple verticals, not just buildings via BBD. A large civils or infrastructure jobbie would get stuff from Power Civils for roads, PowerBridge Modeler for the bridges, Power Rail Track for railways, Bentley Map etc. A process plant jobbie might get stuff from ProStructures, OpenPlant, Substation Designer blah blah blah.

    It doesn't make much sense for all these verticals push stuff too much. Make all those separate dev teams learn viz tools? It would make more sense to have something read the info and assign/attach based on the info. We stand a better chance of keeping up with Luxo.

    The F+P attribute keys are kept with the elements. I suspect DGS info is handled the same way.

    Unknown said:
    As for the projection assignment what I mean is that it should be plain to see and to manipulate from the moment the part is assigned

    Yea.... better to write the tools at Platform level once, and make sure they have all the wizzy feedback-rich features. Again, I see the BBD user using Platform viz tools to do this in BBD or whatever vertical. The definition work would be done at Mstn level, not at the vertical app level. The viz tool should be able to query whatever 'schema' the vertical is using and assign/attach the materials by accessing the element's Mstn 'schema' or setting the Mstn element's bits, not the vertical's.

    Rule sets or scripts would be saved separately. There should be flexibility to bypass 'modified' bits. E.g. if a wall has its projection settings modified, and a new wall is added, the user would re-run a rule set that would scan the model. The rule set would collect all walls or a particular Part and assign the pre-defined materials/projections, but it should be smart enough to bypass the walls that already have the correct materials defined, and 'customised' projections defined. As this is probably an indication that the user wants it that particular way. I.e. re-running a rule set does not undo previous work. If the geometry map for the brickwork in the stacked wall example has a common z-level, I would define the z-level as a parameter in the rule set, not in the element. Maybe, the rule set would need to read parameter off the DGS, but keep the elements as 'dumb' and 'simple' as possible.

    Scale and other 'thematic' variations: Keeping the rule set separate would also make mixing and matching more straight forward. Map F+P definition to materials via look up tables defined in the rule set. Look up scale requirement, and scale up/down material settings etc on that basis. Most of this stuff can't be stored as static ET or attribute info without bloating stuff, I suspect. I guess, it's similar to 'concatenating' info stored as attributes in the elements, and ad hoc context-specific info that is best stored separately.