Vray for SU as a separate process from SU.

[kwistenbiebel1]

Hi all,

It is strange to see Vray using only 2,94 Gb of RAM, while having 8 GB RAM installed.
I know about SU limitations (being a 32 bit app and all that), but sure there must be a way to overcome this.

Some other render software developers have found a way to get workable 64 bit versions (more than 3 Gb Ram adressable) of their apps .

I think Vray for SU would benefit from having a 64 bit version as well.

Regards,

Kwistenbiebel

[dalomar_cg]

Re: Vray for SU as a separate process from SU.

V-Ray for SU without SU is just V-Ray...That would be the ChaosGroup who haven't really put together a full fledged standalone app (there's more to that, but I'll let it be).

Its not strange to see SU (not V-Ray...we aren't a separate task) using 2.94 gbs. In fact I'd say thats pretty good as far as memory usage. Unless you're running a 64 bit OS, your operating system won't be able to even see beyond 3 gbs (and thats if you add the 3 gb switch). So that's almost up to the brim. Even if you are on a 64 bit OS, there are memory limitations for 32 bit applications. Depending on the nature of the 32bit app, the limit is between 2.6 and 3.8 gbs. There's nothing you can do about these limitations, since they are inherent in 32 bit computing.

64 bit is not dependent on us at all. We have the libraries to do it, but the problem is that we are running in the same task as SU. Therefore if SU isn't 64 bit, then we can't be.

[kwistenbiebel1]

Re: Vray for SU as a separate process from SU.

Hi Dalomar,

It's just a pain that an 8 core Mac Pro (running vista 64 bit) gets crippled when using Vray (well not really crippled, but a lot of the hardware potential just isn't used).
You are right that the render export itself from SU will be restricted to the typical 32 bit handicap SU has. Until Google will come up with a 64 bit version, I can live with that. (Well not really , but Google is to blame, not Asgvis).
The other render engines have this handicapped export as well, considering the limited RAM that can be adressed, the not-large-adress-awareness and the typical bombarding of all activity into 1 single process. (all resulting in crashes when the scene is very complex).

But.....once the scene is exported things are different.
The render process itself could be detached from the SU process imo.

The speed gain of using a 64 bit render app outside the SU process itself is significant.
For instance, the 64 bit Fry render version (launched automatically after a direct export from SU), permits me to render faster than the 32 bit version and allows the use of thousands of proxies/instances etc...

A possible solution for VrayforSU would be a real batch render app with a seperate GUI that shows the render qeue.
Clearly VforSU does create some kind of Vray scene file(s) that could be used in a small extra app that can be launched outside of Sketchup.
SU could take care of the export of 'Vray scene files', while the batch app (preferrably a 32 bit and a 64 bit version) can take care of actually starting the rendering process, using the full hardware capacity available as it is totally loosened from SU at that moment.
The seperate render app could be launched automatically after SU export or seperately as a .exe by users choice.

A little batch render app could also solve the current lack of object animation capability,'face me ' components etc... as animations can be exported as a seperate full export of a 'scene file' per (animation)frame from SU.

I am aware of a batch render plugin for VrayforRhino but I don't know if it supports a similar workflow as I describe here....

Anyway,
Thank you for your reply.

[ALTO]

Re: Vray for SU as a separate process from SU.

Biebel, as a Rhino user i can say that we are exactly in the same situation...

What are you asking already exist in Vray for Maya, there's an option inside the plugin that give the possibility to export a .vrscene file (in VfMax too), than this could be manually sent, via command line, to the Standalone Application.

Actually i don't know what exactly ASGVIS could do, but there is a Blender plugin in development (in early stage) that use the Standalone, so something is possible.

[ALTO]

Re: Vray for SU as a separate process from SU.

Just find in Rhino how to export the vrscene file, WOW !!!!

So could we have the vray.exe 64bit?
Should i ask to ChaosGroup directly?
Could i use the one that comes with VrayforMaya Demo? Are there some licensing problems?

[dalomar_cg]

Re: Vray for SU as a separate process from SU.

Beibel,

As I said its not us...bring it up with Google because its in their ballpark. We have the libraries, so we'll make a version of they have a 64 bit SU available.

Again...standalone stuff (ie V-Ray being a separate application/executable) is in the hands of the ChaosGroup. I really don't know what their intentions/plans are for that becoming more than it already is.

Alto + Beibel,
As I said, there is more than that. I'm not 100% up to speed on the standalone, but I'll try to give you some details for what I do know. There is a v-ray stand alone executable, but it is commandline driven only (ie. no UI, very minimal interface). I'm not sure what the actual situation is with the distribution of that exe. We don't distribute it, and I'm not sure if it is distributed with a standard seat of vfMax (although it very well might be). The exe itself needs a vrScene file to be able to render something (no SU file, no Rhino file). In Rhino we do export scene files, (although I'm not sure the specifics other than "we do") so that would be able to work. In SU I believe we export vrMeshes, but I really can't remember if that is correct or even how to go about that. There are other legal issues that go into the standalone as well, and I don't know what the exact situation is with that. I actually was looking for more information on the standalone earlier this week, so once I finally get the answer I'll let you guys know.

[ALTO]

Re: Vray for SU as a separate process from SU.

Thanks Damien, keep us informed! ;D

[ALTO]

Re: Vray for SU as a separate process from SU.

Any news?

[dalomar_cg]

Re: Vray for SU as a separate process from SU.

oh, sorry...been very busy and out of the country for a week (hence my general absence)

Anyway, the big thing is that the standalone requires its own separate licensing. So we can certainly request that CG allows us to use the standalone, but there will other efforts that go along with this. IOW, you might have to specifically install it and take the specific steps to get the license for it...it would "just be there". As for the scene exports we do export 2 types of scenes; the main v-ray flavor .vrscene and our own flavor .asgvisscene. The first is standard and is in a readable format. The second is the binary format that we send to the spawners when using DR. I did talk to Joe and he said that it is possible to have a "scene manager" that would basically take on the responsibilities of the host computer completely separate from SU. So it would load up the scene, send buckets out to whichever DR spawners were connected, and manage the information coming back. The manager would not actually calculate any of the rendering, that could only be done by a spawner.

Thats it for now. I believe the latter of the 2 suggestions there (the manager idea) is more feasible at the moment, but we'll wait and see. Right now there are a lot of things that need our attention so I'm not sure exactly where this falls into the mix.