CRITICAL: Enscape cannot read Texture mapping on VisualARQ objects

  • It's been 2 years and 4 months now since you have been made aware of that bug.

    Well?

    We are aware that Rhino did not get the same support compared to the other CAD solutions, so we are still in the process of going through the lists we created to touch on many different aspects and even bugs that (may) hinder our Rhino users from fully committing to the software. I cannot say when these changes will be added, but I'll definitely post any news here as well once I have some.

    • Helpful

    Hello everyone, I just wanted to let you know that this issue has now been resolved.


    Internally at least, so this fix will be included with our next upcoming release Enscape 3.3!


    EDIT: VIsualARQ support will still require further work from our side.


    We're also in the process of tackling other Rhino-related problems that have been discussed before in the Forum, so stay tuned for further news I'll share with everyone here (and/or in the corresponding other discussions) again in the near future.

  • Demian Gutberlet

    Changed the title of the thread from “CRITICAL: Enscape cannot read Texture mapping on VisualARQ objects” to “CRITICAL: Enscape cannot read Texture mapping on VisualARQ objects (!!! WILL BE RESOLVED WITH ENSCAPE 3.3 !!!)”.
  • Demian So the merger with Chaos Group has been fruitful for Rhino users?


    Does this mean that All of Rhino's Texture Mapping Options will be supported? Not just for Visual Arq objects but also for any Rhino object, group, block, etc.?

  • Waiting for Bongo and RhinoNature support

    Please forward your specific feature wishes to product management through our Voting Portal as well please.


    Demian So the merger with Chaos Group has been fruitful for Rhino users?


    Does this mean that All of Rhino's Texture Mapping Options will be supported? Not just for Visual Arq objects but also for any Rhino object, group, block, etc.?

    Fixing these problems and such is unrelated to the merge actually, it's just that we've increased our staff accordingly and more resources have been freed up to tackle further Rhino-related functionalities/issues!


    The mapping should now actually work for all types of blocks (Once the fix has been added with the upcoming release of course).


    With "All of Rhino's texture mapping options" I'm not so sure what you refer to exactly (feel free to clear it up below of course if we're missing something): We still don't support layered materials or multi-UV mappings, because that doesn't correspond with our material concept so far and we further want to expand this accordingly.


    We hope for your understanding in this case.

  • Demian


    Is this supposed to be working on

    • Version: 3.3.0-preview.7+72357

    The fixes mentioned above will be implemented with release 3.3 soon, in about 2-3 weeks.

  • The fixes mentioned above will be implemented with release 3.3 soon, in about 2-3 weeks.

    Amazing, Demian!


    I just ran into this problem last week and arrived just in time for the solution. So glad to hear it! Thanks for getting this done, this is a huge step for anyone using VisualArq in Rhino and will really enable some great work.


    Do you have a recommended workflow, or should it now work as intended with a typical rhino texture map?


    Thanks again!

  • the bug still persists please see the images below:


    Here is a Rhino file for your use as reference:



    https://www.dropbox.com/s/8zru55gzi1ghj07/bug-01.3dm?dl=0


    In general, you can define "box" mapping at the "OBJECT" level IE: apply box mapping to ALL the materials/textures on an object and map those materials using box mapping.


    -OR-


    you can make a "MATERIAL" have WCS box mapping and than ANY object that you apply that material too will have ONLY that material that was using box mapping use WCS box mapping.



    This is what we need to do for visualARQ objects we need to "DEFINE" the mapping on the Material such that when it is selected as a sub-object material ALL of the mapping will be the same for all objects. Think about a brick pattern used as the exterior face material of a visualARQ wall type. We would want ALL walls of that type to have the SAME mapping for the brick since they are made using the same bricks.


    If we apply box mapping to the wall objects that will affect all of the materials and each wall may have different box mapping coordinates etc. such that the brick texture on one wall may look different than on another wall.


    Unless I'm missing something Demian can you show me an example of what Enscape 3.3 actually "fixes" relative to this issue?

  • Umh... It seems to me that the new version has completely broken support for Rhino!


    The issue appears to be that that objects blocks where their material properties are based on layer are completely broken.



    So while the timber flooring is based on a "Per Object" setting the windows and doors have their materials based on a "Per Layer" basis. This is a MASSIVE issue and one that needs a hotfix ASAP.


    Also, VisualARQ texture mapping is still broken.


    Demian Gutberlet  Pete Chamberlain @ANYBODY!

  • We're currently working under pressure to resolve this issue as quickly as possible. I'll keep you posted alongside the others once we have a solution.


    Nvizeon , I'm gonna get in touch with our developers to get more info on that topic - I will also keep you posted and I appreciate the detailed input.

  • Agreed that WCS global or box mapping gives us the most control over appearance including scale, rotation etc. Very much looking forward to your work Enscape guys! Hope to see the results of your efforts soon.

    It gets really tiring, frustrating, maddening to apply the same material and change the scale/rotatioyn for each every single object. Enscape really seriously please needs to get Rhino's basic functions (material, lighting, edge softening, decal, plenty of examples on this forum from the past few years, none of which has been fixed) working properly.

  • It would be ideal if the Rhino's "MatchProperties" command could be used once the Enscape material is applied to the first instance. This way we could pick up all the details inherent in any material application.

    the trouble with "Box Mapped" or any "OBJECT" applied mapping is that it uses a bounding box that is based on the ONE object that the mapping works for and this "bounding Box" or mapping coordinates will not work for other objects. Hence the need to MAP the material and then that material mapping is GLOBAL and will be the same on ANY object we apply it to. If Enscape would just recognize and respect the RHINO MAPPING on a per material basis then we could apply that material to Rhino Objects - OR - to VisualARQ Sub-Objects. VisualARQ objects are just a special kind of Rhino Block and VisualARQ gives us the ability to apply different Rhino materials to different assembly sub-objects. Think of a typical brick wall the assembly is (inside to outside) Gyp. Bd/metal studs / exterior sheathing/vapor barrier / rigid insulation/air space / Brick. In VA we can apply a brick texture to ONLY the sub-object that is the brick we could apply a pink color to the rigid insulation and textured material to the gyp. bd. and a plywood material to the sheathing. ALL of these sub-objects would have different material mapping parameters therefore we CAN NOT just apply box mapping to the entire assembly. this is where a PER MATERIAL mapping comes into play. the Rhino Object (VisualARQ Wall) has no (Mapping) but each sub-assembly object has a Material used for just that Sub-Object and Each of those Rhino Materials has its own separate "material mapping"