Support Clipping Planes

[Travis Serio_cg]

pretty please.

[dalomar_cg]

Re: Support Clipping Planes

What do you need clipping planes for??? are you cutting rings in half ;D

In all seriousness, clipping planes are an openGL trick, and don't modify the geometry. Also, I don't believe the clipping plane is amongst the geometry that is exported from Rhino when you press render. Therefore, not only do we have to figure out a way to recreate the clipping plane (something which can be done bc its in max), but we're going to have to change the way we go about grabbing all the scene information to track down the clipping planes.

[Travis Serio_cg]

Re: Support Clipping Planes

I didnt want excuses Damien. ;D

LOL. No I know it's not in the rhino render mesh, but it would be nice if I could render my clipped view. I would also like it if we were able to extract our displacement meshes created by V-Ray like how rhino does with the displacement.dll add on. extractrendermesh only extracts rhinos default mesh and not your displacement mesh. You guys obviously have the mesh somewhere. ;D

You guys and Rhino should "mesh" better. lol sorry the pun was there and I had to take it.

[dalomar_cg]

Re: Support Clipping Planes

You guys obviously have the mesh somewhere. ;D

Umm...actually we don't...all of the displacement meshes are created at runtime, used for the specific calculations, then discarded. So during the rendering we have it, but not when we're just sitting around.

That being said, if you want to use the same map within the rhino displacement plugin, then you could use the ExtractDisplacedMesh command. It would be nice if there was a way to automate this, but we don't have scripting access to displacement stuff within our materials yet and I'm not sure if its possible to script adding rhino displacement.

You guys and Rhino should "mesh" better. lol sorry the pun was there and I had to take it.

We should, and we're trying to work towards that as much as possible. Part of the problem is that Vray likes its own flavor of things, so sometimes the Rhino stuff works for us, and sometimes it doesn't. We're trying to manage working with Rhino and bringing all of the available things in from the Vray SDK.

[Travis Serio_cg]

Re: Support Clipping Planes

Yeah, it's a bit strange, especially for new users. It's like yeah do this in rhino, but that in the vray menu, but this back in rhino and that in notepad ;D

I also wish you guys would inherit the zbuffer from rhino. That one can't be that hard to pick up. Its all over the place in the rhino sdk. Rhino does the work, just pick it up.

The VFR zbuffer is a train wreck and pointless when rhino has already done the work and you just have to ask for it. I say that with the greatest respect for the vfr zbuffer option, but lets face it, it's already there so take advantage of it. For those of us that like to composite it makes things stupid simple and very handy. Besides, the other rhino render engines all use it. I have to keep brazil beta installed just to get a quick zbuffer. It faster to swap render plugins and render off the zbuffer than it is to configure vfr's. Food for thought.

Oh, and don't toss out that displacement mesh! I'll take it! I can render up displacement meshes faster than I can do applymeshuvn. If I could then extract that mesh VFR becomes that much cooler and now a modeling aide as well as a render engine.

[Micha_cg]

Re: Support Clipping Planes

The VfR z-buffer could get the min/max distance values from Rhino? Sounds good, very missed options here too.

Render displacement meshes - I'm curious what size this meshes will be. I tested this kind of function per other render engine some years befor and the mesh was very big. Maybe the Rhino displacement tool isn't so bad. What are the disadvantages of the Rhino displacement?

[han3d]

Re: Support Clipping Planes

clipping planes are cool
very cool for complex models so you dont have to split anything

[Travis Serio_cg]

Re: Support Clipping Planes

The VfR z-buffer could get the min/max distance values from Rhino? Sounds good, very missed options here too.

Render displacement meshes - I'm curious what size this meshes will be. I tested this kind of function per other render engine some years befor and the mesh was very big. Maybe the Rhino displacement tool isn't so bad. What are the disadvantages of the Rhino displacement?

I don't know that there is a disadvantage of the rhino displacement tools, but I think it would be nice to keep the texturing under 1 package. I think it becomes confusing to users when you have to utilize some mcneel render tools to trick v-ray into doing things it should already do. Now that Brazil is rounding the corner on its development cycle it's beginning to utilize many of the new features built into Rhino much better than V-Ray is. I personally feel that V-Ray is a better "all around" engine for most users. Brazil has a leg up on its pre-configured shader types and its dispersion but other than that, I feel V-Rays core GI engines are faster and smoother. IR and LC are hard to beat for product rendering. Brazils GI seems a bit slower than V-Ray's. Although I might just biased and that's not true at all, it's just my own personal observations and opinions.

But back to the topics at hand. Rhino is making some good strides to incorporate a lot of features for 3rd party engines to take advantage of. I think mainly because of their needs to support Brazil. I would hate for the ASGVis team to reinvent the wheel on a lot of these. Also, I know that the team likes to be able to take all of the V-Ray code from app to another so they like to keep the code within V-Ray and not rely on Rhino, or Sketchup for things that V-Ray needs. However, I think some of that might actually end up being a weak point for this engine if it's native functionality is less or harder to operate than the native applications own abilities to provide V-Ray with certain information.

I've been doing quite a bit of training lately with V-Ray and I find that if new users do not have good working knowledge of Rhino and Rhino's subtle hidden abilities or add on functionality via dll's rdk's and so on, they get a bit overwhelmed with where to go in the application to do certain tasks.

Whether it's something like using the mapping widget within Rhino or using the texture mapping controls within V-Ray or perhaps using Brazils Zbuffer to get a quick accurate Z-depth map vs trying to figure white points and black points within the VFB options inside of V-Ray. All of these things are hard for them to stream line and grasp without long term experience with both applications to learn these new tools as they evolved like we on this forum have. I just think it would be a more robust experience if much more of this interoperability were streamlined into V-Rays core interface vs hunting and pecking through various commands searching for something that does the same thing that 4 other tools in the same program do slightly differently.


Just more food for thought.

I'm still your biggest fan boy so no worries

V-Ray for the win!

[dalomar_cg]

Re: Support Clipping Planes

To clear things up, we're not steering away from Rhino features because we don't want to support them. We're making sure our product stays as stable and reliable as possible. All of those great features that are out are not released products yet, which means they may be subject to change at any moment (and for reasons we have no control over), and they may have bugs that might affect usage or stability. V-Ray is a released product and that means we have to be as stable and reliable as possible. Incorporating other products that do not have that requirement is risky business for us and already caused us a big issue.

Once these products become fully incorporated into Rhino and become finalized then we will be looking to support them within our product. But until then it is in our interest to be safe rather than sorry. As we progress we are going to be looking more carefully at workflows within Rhino (and SU and...) and that will inform how we change and adjust our product to better suit the environment that its in.

[Travis Serio_cg]

Re: Support Clipping Planes

I am with ya Damien and I agree. But you know me, I am needy! ;D Just ask Joe.

[dalomar_cg]

Re: Support Clipping Planes

Oh, I know I'm just making sure people know what our stance is and that you all don't think that we're not hearing what you have to say. We've already got burned by sticking our head in, so we're being a bit more cautious at the moment. Again its not that we don't want to (RDK and the other tid bits have good things to offer), its that we need to set the priorities...and apparently people like it when they can start up vray ;D

[han3d]

Re: Support Clipping Planes

you might have both stable and beta releases at the same time and people can choose one of the two options
if you wait for mcneel to finish rdk you will wait a long time and rhino 5 will come
you better start coding and let us do the crash testing