the link on the download page to the preview "beta" version is not working it just reloads the "current version" download page.
I just made my own icon button.
this Rhino command line command brings it up
- Version: 3.5.0-preview.9+93360
Enscape Version listed above
I can't find the account button or the license management button in Enscape for Rhino.
I see an Account icon in SketchUp but not in Rhino and there seems to be no way to activate or deactivate Enscape license in Rhino.
Right away, we've indeed filed a dedicated bug for the behavior detailed by Nvizeon "Enscape does not recognize the mapping of the material that has WCS box mapping." which we're looking into resolving as quickly as possible. <<<Thanks for adding this to your list of potential fixes
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"
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.
as you can see in the images I posted the VisualARQ walls on the right have a material that is using map channel 1 but when two walls intersect each other the mapping gets rotated 90 degrees. Since this is in map channel 1 Enscape replicates it the same way we see it in the viewport.
when we change the "material" to use WCS box mapping and apply that "Material" to ONLY the exterior finish of the wall assembly using the VisualARQ wall styles editor the material displays correctly on all walls even when two walls intersect. (This is the behavior we want) and How we want to apply materials to separate components of a VisualARQ multi-component object.
Enscape does not recognize the mapping of the material that has WCS box mapping.
the cubes also have that material applied and they are native Rhino objects so it's not JUST a VisualARQ issue.
see the attached image that hopefully clarifies the issue.
the bug still persists please see the images below:
Here is a Rhino file for your use as reference:
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.
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?
Is this supposed to be working on
- Version: 3.3.0-preview.7+72357
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.?
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).
Why is this thread/issue marked as resolved?
I see what you mean, but if you apply a box texture map onto those VisualARQ objects it renders correctly within Rhino:
Did you apply the box texture mapping to the OBJECT or to the "sub-object" in VisualARQ a wall can have an exterior Material, and an Interior Material in fact a wall could be made up of several separate "materials" Studs, Insulation, Sheathing, gyp. board, Siding, etc., and each of these "sub-objects" can have its own (texture)/material applied to it. Wood for the studs, pink grid pattern for the insulation, white for the gyp. bd. and wood siding for the siding.
Rather than selecting EVERY VisualARQ wall object and applying box mapping to the "WALL ASSEMBLY" it's cleaner to create a box mapped material and apply that in the VA Wall style's definition to the sub-object IE: the exterior siding. Then you only need to edit the wall style once and ALL walls of that style are automatically updated. It's a much more simple method than doing the texture mapping on a per-object basis.
I can also see how Raytraced does not work on either of the models, so there is some issue within VisualARQ as well.
Yes, Ray-Traced rendering engines IGNORE any material applied to VisualARQ objects.
External Programs like Lumion render VisualARQ objects correctly I suspect because the transfer process makes extracted render meshes of the visualARQ elements.
Anyway thanks for looking at this and I hope VisualARQ, Enscape, and RHino can resolve this since the three applications together make for a very powerful BIM workflow, and presently not being able to RENDER the VisualARQ objects in Enscape is a deal-breaker.
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
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.
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.
Yes From what I see the only way to Deactivate the License in V3 is after you start a render. whereas before the settings were available directly from the toolbar even without Enscape running.
I've unloaded V3 I don't think it's quite ready for production workflow yet.