Posts by Nvizeon

Please cast your votes in our two ongoing feedback polls here and here!

  • CRITICAL: Enscape cannot read Texture mapping on VisualARQ objects

    Quote from Applied Visual Chris

    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"

  • CRITICAL: Enscape cannot read Texture mapping on VisualARQ objects

  • CRITICAL: Enscape cannot read Texture mapping on VisualARQ objects

    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?

  • Re-linking Assets

    If you open the enscape object (block) with block manager inside Rhino and then inside that "block" insert the same Enscape asset (Tree, Person, Etc.) then ALL instances of that block (IE: Enscape imported assets from SketchUp) will update, then just position the "Rhino" enscape asset the same location and orientation and delete the SketchUp imported proxy. Now when you close the block (asset) all of the similar blocks will now have the Rhino Enscape asset that will render in Enscape.


    So if you have 2000 assets but only 190 unique blocks then in theory you only need to edit 190 blocks to have all 2000 assets render correctly in Rhino (Enscape)


    Still a pain but a smaller pain than redoing 2000 assets.


    essentially you are making a nested block where the original block is the asset imported from Sketchup and you are "nesting" inside that block the Rhino Enscape asset, then deleting the imported geometry (proxy).

  • textureMapping inVisualArQ wrong in Enscape render

  • textureMapping inVisualArQ wrong in Enscape render

    Quote from rheinason

    It's only related to WCS Box Mapping if the materials you're using have box mapping. And it's not related to the way VisualARQ does texture mapping, but rather that Enscape are using the wrong RDK.

    If you take enscape out of the equation there are still issues with the way VisualARQ objects are texture mapped. Particularly when two walls intersect. With Mapping Channel 1 the orientation and the size of the texture changes on each side to the wall at the intersection. With Box Mapping this is not the case.


    As you can see in the attached images Before the file is rendered in Enscape the texture mapping glitch is present.


    Box Mapping is effectively hiding or compensating for the way the VisualARQ objects are mapped. You can see in the Enscape rendering that the box mapped textures get super enlarged...but it also reveals that even on the box-mapped VisualARQ walls the wall that is intersected has two different orientations of the material in Enscape.


    So as I see it VisualARQ is not mapping textures properly on walls as they intersect each other


    AND


    Enscape is not reading the box mapped textures correctly.


    Both of these are true and both contribute to undesired results.


    I've attached the Rhino FIle for anyone who wants to verify the issue I am seeing.

  • official 3.0 problem

    Yes, you can not submit a feedback report if your entire computer is BSOD. In my case SketchUp just FROZE I was completely locked out of SketchUp and Enscape etc. I had to CTRL+ALT+DELETE to stop SketchUp.