Blocks and materials

[Micha_cg]

Hi,

the material of nested blocks without external file reference can not be edited, but the good news is, if the block base on a external Rhino file, than the materials of this file can be edited and refreshed in the parent file. During the import of a block, the materials will be imported toO and can be manipulate.

Also, it is possible to export an internal block to an external file and to edit the material at the external file.

All together, blocks works better than thought.

-Micha

PS: Tests done with Rhino4.

[Micha_cg]

Re: Blocks and materials

I'm not sure, does blocks help to bring down the memory usage at the current VfR?

[joe_b]

Re: Blocks and materials

I'm not sure, does blocks help to bring down the memory usage at the current VfR?

We're still plugged directly into the CRhinoSdkRender implementation. Which used to mesh each block instance individually and pass it to VfR. I am not sure if they changed that implementation in Rhino4 or not.

[caje]

Re: Blocks and materials

Micha when you say blocks, you mean importing an finisehd object with all off it materials, into the scene for rendering?

[Micha_cg]

Re: Blocks and materials

Yes, for example. It's good, if you have many copies of an object in your scene. You could edit the external reference and all objects are updated after a refresh.

[Micha_cg]

Re: Blocks and materials

I'm not sure, does blocks help to bring down the memory usage at the current VfR?

We're still plugged directly into the CRhinoSdkRender implementation. Which used to mesh each block instance individually and pass it to VfR. I am not sure if they changed that implementation in Rhino4 or not.

I create a high poly sphere, create block definition - memory usage during rendering 250MB.
If I render 6 copies, the RAM usage is 750. If I explode the spheres to objects, than the RAM usage is 870.

An other test is done with a large texture assigned to the blocked sphere.

6x blocks 960 MB
6x spheres 1300 MB

So, blocks help to save the memory. I'm not sure, it the best possible result what can be get with instances. Joe, maybe you can discover it once a day, if the new release is ready. Please set it at your list of interesting VfR issues.

[joe_b]

Re: Blocks and materials

I guess they did change how blocks are handled for v4 - thats good.

[caje]

Re: Blocks and materials

Yes this s also the thing you had in Lightscape and its great!

[dynamooo]

Blocks and materials

I have only just become aware of this problem. But I think people suggesting solution are getting the wrong end of the stick.

As I understand it, you can create blocks as either embedded or with a external file. The problem with external files is the paths, as Rhino cannot do relative path etc..

So anyone who isn't concerned with file size would prefer in my opinion embedding blocks, its alot let hassle in so many respects.

So the problem is vray material manager, when purging doesn't recognise the nested materials. They are still applied and will render, but I cannot edit them.

So in my humble opinion vray when purging needs to to check at nested level what to remove.

I cannot explain how important this is, the reason being rhino+vray currently are very squeezed for memory due to the 2 year update cycle we are trapped in(even thou there is a 64 WIP available the just needs very minor changes to make it rhino 5 friendly). Blocks save rhino memory use, which frees memory when rendering.

I hope you guys can see the problem here.

As a side note, could we not just have the current version of vray ported to Rhino WIP? No upgrades just simply porting it in its current state. It would be greatly appreciated by many. McNeel have been running online webinars on rhino WIP, its very stable and pending release soon. It would release alot more memory for rhino to move around in, and make the need to use block not so crucial.


Give us rhino users a break, you have a good user base, resting on you laurels for soo long is making many ask questions.

[dkendig]

Re: Blocks and materials

1.05.30 doesn't work with the Rhino 5 wip? Have you tried it?

[dynamooo]

Re: Blocks and materials

I only have 1.5.29

There is a 1.5.30, if so I need to go speak to the boss, nothing more stupid that being a version behind.

[dynamooo]

Re: Blocks and materials

yeap just testing it now, and it doesnt work says the plugin in 32 bit...

[dkendig]

Re: Blocks and materials

oh sorry, 1.05.30 was the old SketchUp version, .29 was rhino, you are correct. You are correct though, the 64bit build of the Rhino 5 wip doesn't work with our 32bit plugin. Our upcoming release will support 64bit.

[dynamooo]

Re: Blocks and materials

up and coming you say...

please give us some light in this tunnel, I am coming from 3ds max, this is killing me its forcing me to export to max for rendering....

[dkendig]

Re: Blocks and materials

We've been rewriting the entire core of our plugin. We've talked about it in a few places on the forum, but since there's been nothing to put in anyone's hands, we haven't really said much about it. We use about 75% of the same code in both V-Ray for Rhino and V-Ray for SketchUp, this has always been the case. Our material editor, option editor, texture editor, light editor, and our connection to V-Ray itself (which is written by the Chaos Group), all are shared between our products.

We found that the old way of doing things (which was mostly in C++) made the development process rather slow and cumbersome. It was difficult to add small changes here and there, fix bugs, add custom changes, add features, etc. So we dumped the majority of our old code and started pretty much from square one. We decided to tackle SketchUp first, since that's the product we've always had the most trouble with. It's API isn't as render friendly as Rhino's. We are still working out some bugs, but we are able to roll out updates at a fairly rapid pace (especially when compared to our old development cycles!).

We have been working on Rhino as well, but the majority of the code up until earlier this year, applied to both products, and wasn't specific to just SketchUp or Rhino. V-Ray for SketchUp bugs took priority after the product was released in April, but we have pretty much nailed all of the bugs that are SketchUp specific at this point, so we have started turning our attention back toward our core, and Rhino. We only have 2 developers, so it's hard to really focus on both products at the same time (at the moment anyway). Once we get them both up and running with our new core, it will be MUCH easier to roll out updates for both V-Ray for SketchUp and V-Ray for Rhino at the same time.

I will be posting some news about our V-Ray for Rhino development progress some time this week on our blog.