Texture mapping behaviour

Hi Franscesc,

I stumbled upon another strange issue, maybe you can elaborate a little bit on the way texture mapping is working for VA objects?
I made a short video using the octane rendering engine:

https://we.tl/t-TRUi8pV15B

I think I understand that VA objects are behaving block like, however since there is no place within the VA object / styles properties to define texture mapping, I wonder how this is actually working…

It would be a very useful thing IMHO to be able to define a universal texture mapping e.g. boxmapping (normally in Architecture this would be good 90 % for all objects) 1m X 1m X 1m, which would be used for any VA object and could be overridden on a per object base. The sizes for the different textures could then be defined within the material.

best

Andreas

Anybody?

Hello,
Take a look here: flamingo textures. Maybe it has something in common with your problems. With Rhino 5 there were no issues with rendering VA models.
Cheers, Jaro

Hi @walther,

I have made a test with a Rhino box, VisualARQ wall and a Rhino block and the render output is ok, the mapping is almost the same for all of them. Did you use a Rhino material or an Octane material?

Could you send me your example model with the texture to visualarq@asuni.com ?

Hi Ramon,

attached please find another video and the according file… something is not working here…

best

Andreas

Hi @walther,

I see in the video that the texture doesn’t update after you change the values. This is an issue that we already know and we will solve soon. Currently you have to select the object and run _vaUpdate each time to see the changes.

…more weirdness…

… a picture rendered with the rhino render engine shows the correct mapping:

however, using the octane render engine shows a completely other picture :

this is actually the same appearance you will get if you completely delete any texture map, so it seems that VA objects cannot transmit their texture information to the octane render engine.

Run the Rhino _RefreshAllTextures to make sure Octane gets the new mapping values.
We will try to solve this issue for future versions.
Kind regards

1 Like

…this does not seem to do anything here…

Andreas

… at least the _vaUpdate command is able to update the viewport, how ever that is a veeeery cumbersome workflow and not really usable.

Please fix this, I also wrote a message to Paul Kinnane ( paulphysicalc ) in the otoy octane forum…

best

Andreas

I can’t change the Uv maps in visualarq objects.
I can’t use the box mapping as a displacement map in octane render.
The result is that i can’t use displacement maps in visualarq and octane for rhino neither using uv maps (thanks to visualarq) neither using box mapping (thanks to octane render). So?

Hi @lopez,

Box mapping is possible on VisualARQ objects, but just to the hole object, not to subcomponents.
Is it not working just with Octane Render or also with Rendered display mode and with Rhino Render?
About the displacement map for Octane Render does it work with Rhino blocks?

Kind regards

Hi Ramon,

Thanks for your message.

Here it is the opposite. To use box mapping (that I can’t apply to the whole object), I need to enter inside the Visualarq object editing the block and applying the box mapping (and this is good because I can also refer to the subobjects).

Now I’ve created a macro to speed up the process to:

1_Edit the block in place

2_ Choose the subobject

3_Apply the box mapping with relatives options to the subobject.

So now, all it works right (Octane’s materials can’t use Displacement map with box mapping, but it works because the octane material has the UV map while the Visualarq sub-object now have the Box Mapping).

The result is that I have resolved the problem.

Anyway, I ask you, if possible, to take care of the Visualarq UV mapping with some option directly inside the style, to speed up and simplify the process for renderings.

Thanks,

Regards,

Roy

Hi @lopez,

Ok, so we will think on an easier way to set up the textures for styles and its subcomponents.

Kind regards

Hi Ramon,

Thank you very much. You’re doing a great job.

I’m working with excellent results using the hidden visualization on plans and sections. So I would like to ask you:

Why (or when) to use the command to create the 2d representation and 2d sections, if the 3d hidden view works already good to create 2d Layouts and details? In what cases do you suggest to create 2d plans and sections that have the issue to filling the 3d model area (as happens, of course, using the traditional, but old, rhino way of 2d representation)?

Thanks,

Kind regards,

Roy

A9E9E36436E5487FA1F7DE5A49C08963.png

Hi @lopez,

Actually we advise to always use “real” views with Hidden display mode, so we are very happy with your comment :slightly_smiling_face:.

2D views can make the model really slow and have some limitations. Currently the main advantage compared to “real” Hidden views is the possibility to export the lines, for example to dwg.

Kind regards

Yes,
I think if you resolve in other way how to export dwg, the 2d views method will be useless, only a repetition of a better tool. I think is important to improve the Vector printing quality in hidden mode, that however is already good by now (that’s really one of the killer feature of VA, as tell Francesc, for me too). In Rhino 2d documentation is a nightmare (or very old style if you prefere). The only dynamic tool (“section tool”) is a plugin!

KInd regards,
R.

1 Like