lowering parsing time. Ideas?

[kwistenbiebel1]

Hi all,

It has been a while since I used Vray, but I am happy to try it again on the SR1.5.
I must say, great improvements there!

The only thing that bothers me a bit, though, is the very long export time when hitting the render button.
I know ungrouping/exploding components and groups helps, but in a lot of models you just don't want to do that as it can ruin your geometry.

Don't know why the export routine changed from the first Vray version as I can't see the difference in render quality (the moderators say the export is more accurate).

So unless we get the quicker parsing method back as an option, I am all ears to know if there are methods to overcome this.

For a final rendered image I don't mind the longer parsing time, but since Good rendering is about trial and error and making a shitload of test renders, the current parsing time kills the workflow .

On my 8-core rig, the parsing of the file takes considerably more time than the rendering itself...seriously

Regards,
Biebel

[Jackson_cg]

Re: lowering parsing time. Ideas?

Hi Kwist,

See my post below for the fix for this problem (I'll edit the topic title so it's a bit easier to search). I saw parse times drop from 20 minutes to 20 seconds after running this script, it's a real VfSU gem.

http://asgvis.com/index.php?option=c...0&topic=5386.0

You can download the ruby script which "fixes" (i.e. works around) directly from Sketchucation here:

http://www.sketchucation.com/forums/...?f=180&t=13711

It makes permananent changes to your skp file so you may want to "save as" knowing how many other render progs you use with SU.

I'm going to ask the script author Matthieu Noblet if I can host it on Rapidshare so it's easier for VfSU users to get hold of. It should be bundled with VfSU IMO!

Regards,
Jackson

[kwistenbiebel1]

Re: lowering parsing time. Ideas?

That's some very interesting input there Jackson....
I will have a go on that.
If it really cuts down the export time considerably then yeah, it should be a script within VfSU itself.

Thanks for that. I'll post my findings on the script here.
On the other hand, I would not mind if Vray got back the old export algorythm that exported the so called 'degenerate triangles', as to be honest, I can't see the difference in the output (I tried the same file in both the eldest as the newest Vray version).

Cheers,
Biebel

[Jackson_cg]

Re: lowering parsing time. Ideas?

It really does cut parse times dramatically, but the catch is that you you lose SU's useful "material by group" function i.e. if you have several identical car components whose bodywork is default textured so you can paint them all different colours with one click then that no longer works after running this script. Nevertheless, Iit hasn't disruptied my SU modelling process as much as I thought it would, especially as any new components added to a skp file still have their default texturing function intact. The massive gain in parse time is well worth the slight loss of SU functionality IMO.

[dalomar_cg]

Re: lowering parsing time. Ideas?

beibel

There were significant issues with the old scene exports, so its not that we're just saying its more accurate...it is. In the old scene exports groups and components were exported inconsistently, so materials would be missing (causing objects not to render), texture coordinates wouldn't be retrieved correctly (causing maps to be messed up), or some geometry would not be retrieved (causing geometry to disappear). There were also issues regarding the exporting the scene a the correct physical scale. Although this wasn't as significant issue in the first version, which did not have photometric lighting, the addition of that feature would have been absolutely useless with the scene not exporting accurately.

Its not that we like how long the current scene export takes. In fact, its the biggest thing that we'd like to change about VfSU. However, we're not going to sacrifice the changes that we made just for speed because the sound of disappearing geometry/materials and incorrect lighting doesn't sound too exciting for us. Not only that, the scene export is not a switch that can be flicked on and off. Its a significant aspect of our render process and highly connected to both how we work in SketchUp and connecting with V-Ray. So having two processes would be such a significant under taking that it would hault all other development, which you guys probably wouldn't like.

There are techniques out there to help speed things up. The script in Jackson's post is a great one. Also, organizing your scene in a way that minimizes nested components helps the issue as well. So you're not without any options within the new method. In the end this goes back to SketchUp since they don't have a framework that is setup for renderers to retrieve geometry. Until they do that, any scene export process we come up with will still have to work within the same framework of retrieving every vertice and face manually.

[kwistenbiebel1]

Re: lowering parsing time. Ideas?

Thanks for the explanation.
I guess we can live with a longer export time as it makes other important things possible.

The new version is a lot better and faster at the texturing and setting up Vraymats than the old one so that is definitely a big improvement. Very good!

I do miss the quick exports of the old Vray, though, as it made test renders really easy.

Somehow I would love two have the both versions combined into one. The new material handling together with the old parsing .
You can't have all

Cheers,
Biebel

[kwistenbiebel1]

Re: lowering parsing time. Ideas?

Thanks for the help here in this thread.
Jacksons link to the ruby was helpful.....

However, the long parsing time makes VrayForSketchup not feasible for me.
It is just too long.

The new material system? Fantastic!!
But the new longer parsing time (for large files)? No go.

I hope it will be fixed in an update.

[thomthom]

Re: lowering parsing time. Ideas?

Can this be made a sticky? It answers some questions that often gets asked here.

[goutham_cg]

Re: lowering parsing time. Ideas?

hi guies,
i download the script and copy it into plugine option , then opened su6pro ,and went to plugine option and click cg material option then a question is asked to me about applying cgtextures to blocks/components i answered yes,after that it was taking hours
to respond ,now it is reaching about 2 hours still didn't respond...i am working on a 90mb su file ,what might be the problem ,or actually it does take much time? or any problem with the system...please help me... thank you.

[thomthom]

Re: lowering parsing time. Ideas?

Yes. This ruby might take a very long time to complete. Best to perform it while you're planning to be away from the computer if it's a large model.

[goutham_cg]

Re: lowering parsing time. Ideas?

thank you......after 2 hours su responded and i click render but scene doesn't render ...!!!i don't know the problem ...i have posted the error details in bugs page ,if any one knows the solution please help me... thank you.

[kwistenbiebel1]

Re: lowering parsing time. Ideas?

I imported one of my SU models in Cinema4D and rendered it using VrayforC4D.
Parsing time using VrayforC4D? 3 seconds ...as opposed to almost 10 minutes using VrayforSU....

[dalomar_cg]

Re: lowering parsing time. Ideas?

I'm not surprised...almost all other 3d apps have a simple, efficient way of retrieving the geometry from the scene. SketchUp doesn't and it has to be done manually. I would be quite surprised if the SU parsing was faster than any other app out there...Thank Google.

[Jackson_cg]

Re: lowering parsing time. Ideas?

Damien,

I know we've been over this many times, but I still don't understand one thing: why is it only VfSU which seems to run headfirst into every SU export/parse shortcoming? Even if SU is a pile of crock-coding, AFAIK the Podium and Maxwell plugins work around it (by what means I have no idea).

Either way, the ways things are developing (or rather not) at SketchUp HQ, I am actively working towards fazing out SU (or at least minimising it's use) from my workflow in favour of Rhino. I'm sure it will still have it's uses for years to come, but until it's becomes multi-core compatible and high-poly capable it'll be less and less relevant for professional CAD modellers. Who knows... assuming that one day (year? decade?) surely it will support multi-cores maybe they'll recode it and build it from a sounder foundation? Here's hoping!

[dalomar_cg]

Re: lowering parsing time. Ideas?

It mainly comes from us reading the geometry directly out of SU. Most of the other render engines are exporters, so they can save out there format through the I/O SDK as opposed to dealing with the Ruby side of things. Ultimately, we're going to need to find a ground up solution on how to make the process better. Trying to modify our current process doesn't offer us enough improvement and is likely to cause more harm then good. During the development process for the next full version we'll scratch our heads, go out to the woods for some soul searching, and hopefully come back with a better process.

I'm going to leave my comments on SU development out, but I'm glad to hear that you're moving over to Rhino (I've made it no secret that I'm a huge Rhino nut). Rhino is really a great app and its capabilities are growing with every version and every plugin that they put out there. Its really flexible and you can make it dance around a fire if you want to. IMHO SU just isn't something that is suitable for professional use as it lacks the ability to be able to create and deal complex work efficiently...