Price of V-Ray Stand Alone Version?

[GaryR50]

Does anyone know how much the stand alone version of V-Ray will cost when it's released?

 

Gary

[Ernest Burden III]

or what sort of files it will take for input?

[mbr]

Very interesting. Very vague!

 

So do they mean stand alone, as in do it all, or that if you have VRay on one computer, you can render on another without Max/Maya on another? I fearfully think the latter as I can't imagine they will make an interface, material editor, lighting, etc., etc. Who knows, though.

 

Personally, I am all for it. I hate the idea of spending tons of cash just to have Max/Viz sitting there to hold a rendering program (I like Final Render, though).

[Ernest Burden III]

My GUESS is stand-alone means that it will accept certain scene files as input--like a MAX file, or a LWO, like the way Renderman has RIB files, and it would render from that. So you would be feeding it all materials, etc. But there are materials specific to Vray, so then it would probably have to use a GUI to substitute those in. Heck, what use is speculation?

[Christopher Nichols]

Vray will most like use its own file format. Simliar to how mental ray uses MI files and renderman uses RIB files. When you hit render in MTOR (the traditional Maya TO Renderman program) it will create a rib file and send that rib file to renderman. I suspect that the same will be true in Vray. so a translator can be written for maya, max, lw, houdini, etc...

[luckytohaveher]

It will probably resemble ART-VPS's Renderpipe netrib. Your plugin creates a file, sends it across the network to a waiting machine, and then renders the result (in ccccccccccpppppppppppppppuuuuuuuuuuuuu time). The only difference will be of course the generic cpu usage vs. dedicated silicon...

[GaryR50]

That would be "stand alone" as in a separate program that is meant to be marketed as a self-sufficient renderer, MBR. As it is, currently, it's just a rendering plug-in for 3D Studio MAX.

 

As for files it will import, I'm sure it will accomodate all the same formats it does now, which would include 3DS, of course, as well as DXF, so we SketchUppers will be covered. As for output, it will probably output in several graphics formats, including JPEG and/or BMP.

 

Gary

[Christopher Nichols]

That would be "stand alone" as in a separate program that is meant to be marketed as a self-sufficient renderer, MBR. As it is, currently, it's just a rendering plug-in for 3D Studio MAX.

 

As for files it will import, I'm sure it will accomodate all the same formats it does now, which would include 3DS, of course, as well as DXF, so we SketchUppers will be covered. As for output, it will probably output in several graphics formats, including JPEG and/or BMP.

 

Gary

 

Gary... Pretty sure that the Vray rendering interface will not work as you say. I will work in the same way as MentalRay does or Renderman does. You will submit your rendering from within the 3d package (max, maya, etc..) and it will create a vray file and submit it to the rendering package on the fly. Seamlessly to the user. This type of rendering pipeline is well know, and sort of a standard for standalone packages. Both renderman and Mental Ray doen't really have an external interface, and I don't think Vray will either.

[Christopher Nichols]

It will probably resemble ART-VPS's Renderpipe netrib. Your plugin creates a file, sends it across the network to a waiting machine, and then renders the result (in ccccccccccpppppppppppppppuuuuuuuuuuuuu time). The only difference will be of course the generic cpu usage vs. dedicated silicon...

 

Unfortunatly dedicated silicon, as you call it, has not proven to be as fast as clever programming on a CPU yet. If it was, places like ILM would be purchasing a ton of them rather then spend the money on racks of "generic" computers with prman and mentalray licenses. However, this will be changing. GPU's as opposed to CPU's will soon be the future rendering pipes. Especially with products like this one:

 

http://www.nvidia.com/page/quadrofx_3000g.html

 

and the innovations of things like of genlock and framelock

[GaryR50]

Chris, I'm not sure exactly what you mean by "submit," in this context, but a stand alone renderer works independently of any other software. It is a rendering application in its own right (think Artlantis, only MUCH better). That is what V-Ray will be when the stand alone version is released next month. You'll be able to render any model file from any modeler. That's the whole point. As it is now, it's only used by MAX users, because it's currently a MAX plug-in.

 

Gary

[Craig Ramsay]

That is what V-Ray will be when the stand alone version is released next month.Gary

 

Its not the stand alone version of V-ray that will be released next month, it is a v1.5 max plugin update. Once this is released Chaos group will concentrate on the first release of the standalone version of V-Ray.

 

Craig

[GaryR50]

Thanks for the correction, Craig. Are you associated with the V-Ray production team in some way? Do you know when we might expect the stand alone version?

 

Gary

[Craig Ramsay]

Thanks for the correction, Craig. Are you associated with the V-Ray production team in some way? Do you know when we might expect the stand alone version?

 

Gary

 

No i'm not associated with the V-Ray production team, just a user. Here is the official word from Chaos Group:

 

We would like to shed some light on the nearest future of V-Ray.

 

As the aggressive development of V-Ray has lead it far beyond what we promised in the beginning, we have decided that the next major version of V-Ray will be 1.5. Even though we have included a lot more than we initially planned, 1.5 will still be a free upgrade for all current V-Ray users. Massive polygon rendering will be included the Advanced version for free.

 

Our latest estimates are that V-Ray 1.5 release candidates will be coming at the beginning of May 2004. In the mean time, new V-Ray builds will be available to a very limited number of people through our internal builds. This means that all new features will be included in the internal builds only until we release the 1.5 release candidates. We do this in order to have more freedom while reorganizing the VRay core and as a precaution against software piracy as well as the competition who made it a habit to rip features directly from V-Ray. Any registered user can ask us for the internal build, but we will grant access on a case-by-case basis. If we do not reply within 48 hours of your request, please consider this a refusal.

 

Furthermore, once we have released V-Ray 1.5 final, we will concentrate on the first release of the standalone version of V-Ray, as well as connections for Alias MAYA and other platforms. As we have taken special steps in the past few months to make V-Ray practically a standalone module, the first release should not take too long. This step took us a lot longer than we promised, but we will make up for the much shorter development times that we require from now on. Which means – sooner release date for V-Ray final for MAYA. The first V-Ray builds for MAYA will be available for public beta testing.

 

After V-Ray 1.5 is released, we will continue adding extensions to the basic core such as additional geometric primitives (render-time meshsmooth'd geometry), shaders etc.

 

V-Ray team,

Chaos Group

[GaryR50]

A bit vague, but it at least confirms their plans to release a stand-alone version. It's not quite clear as to what that will consist of, exactly, and as to whether it will be able to texture and render imported DXF and 3DS models, as I'm hoping it will.

 

Gary

[ch83575]

A bit vague, but it at least confirms their plans to release a stand-alone version. It's not quite clear as to what that will consist of, exactly, and as to whether it will be able to texture and render imported DXF and 3DS models, as I'm hoping it will.

 

Gary

 

I think you should check out how most other high-end renderers function (ie. prman or mentalray). I dont think that it will just render a DXF because there is no way to declare a v-ray material in a DXF file. If there was some sort of shader declaration in your DXFs then it would no longer be in the DXF format (ie MAX probably wouldn't open it any more). Therefor chaos group will probably do it the same way as everybody else and use some .vray file format. If i had to guess i think it will resemble a .rib, but it will not be a .rib because the feature set is so drasticaly different from prman and v-ray. You should really check out how mentalray works as a standalone, not the plugin renderer (which is actualy just a glorified file exporter).

 

The reason for Chaos to release this renderer as a standalone is not so you can render sketchup models. As much as we like to think that the architectural visualization market is large and untargeted in the CG world... it isnt. We are all small fish (except from maybe OCEANPIC and maybe a few others that would constitute medium fish). The reason for a standalone is to make v-ray more attractive as a tool to be integrated into a large pipeline. When i say integrated that is like R&D... custom file converters and pipeline tools. WAY above my head, and probably the rest of us too.

 

What to look forward to: you probably wont be able to find a way to use the v-ray standalone effectivly with sketchup (you probably lack an R&D team). But @last Software might! They could integrate any or all features of v-ray into sketchup and remarket the v-ray standalone as a sketchup plugin. That is the idea.

 

(if it isn't sketchup you want to use to create DXFs, sorry. I just thought it made a good example)

 

-Chad

[GaryR50]

How about an OBJ file, Chad? It's Maya's native format, and, with the plugin for OBJ export, a SketchUp user "should" be able to export an OBJ that is accompanied by a folder containing texture data. That would work, wouldn't it?

 

Gary

[Christopher Nichols]

Gary... I really hate to try to correct you one more time. Standalone rendering does not work that way. If you used mental ray in the last version of MAX or Maya, you will see that it seems "seemless" to the user. Your file is created within the 3D package and submited as a rendering within that package. Then a plugin within that packages creates a MI file (for mentalray), or a RIB file (for prman), and most likely a vray file (for Vray). That file is then submitted (simlessly to the user) as a EXTERNAL command to the EXTERNAL rendering engine, such as: "prman myhouse.000.rib" Having it an external program delays the process of rendering because it has to parse your file and generate the rendering file. Sometimes in Renderman people wait several hours for ribgen before it is submitted to the rendering engine. There are even several rib parsers for maya. MTOR (which stands for maya to renderman) is developed by Pixar, and there is another one called Mayaman, plus many big effects companies develop their own. Sony Imageworks actually has an external program which maya writes to, and that program is where the lighting is done, it then submits a rib from THAT program to Prman.

 

So if you want to render a OBJ file in Vray, you can import it in MAX and submit it via the Vray plugin to the vray rendering engine.

 

The only file format that prman supports in RIB, which is created out of maya using mtor. I suspect that the same is true for Vray.

 

I have a LOT of experience with external rendering.

 

The big reason that Vray MAY be going to an external rendering engine is to attract more BIG effects companies. Rendering parsers are easy to create, since the CORE rendering lies outside the 3d pipeline. So once it is standalone, parsers can be written for almost any program that supports external rendering (maya, softimage, max, houdini, lightwave, etc...). If scketchup supports external rendering engines (don't think it does) a parser needs to be written within scketch up to render. Otherwise, you will have to export it to file format (such as OBJ), open it in a package like maya or max, and render it in Vray via a Vray parser.

 

Anyway, I could go on and on about this if you woul like, but I think you get my point. The basic point is that to the basic user going to standalone will should seem almost exactly the same to user:

 

Now

Within max hit the rendering button -> calls vray plugin -> display image in VFB

 

What user sees

render button -> image in VFB

 

Later (my best guess):

render button -> parse into vray file -> run external command of vray on file - > display image in VFB

 

what user sees

render button -> image in VFB

[GaryR50]

Chris, it seems to me that what you're describing is not a true "stand-alone" renderer, but a plug-in. Artlantis is a prime example of a stand-alone renderer. It is a self-sufficent program that is specialized in rendering, and it can render model files of various formats, imported from various modelers, including SketchUp. If the V-Ray "stand-alone" version isn't going to be anything like this, then it is not a true stand-alone, which, by the very name, implies something closer to Artlantis.

 

Gary

[Christopher Nichols]

I think that everyone will agree that Renderman is a standalone rendering engine, they will also agree that mentalRay is a standalone rendering engine. Those operate just the way that I explained it. The reason that they are is that they are executed outside the 3d package. A plugin is used to LINK the 3D package to the standalone rendering engine. But the rendering is done OUTSIDE the 3d package. I use renderman everyday. We use mtor to link between maya and renderman (mtor stands for maya to renderman). We create our shader in Slim (a plugin for maya) and submit our renders with mtor (another plugin for maya). mtor takes our data and turns it into rib file.... call it rendering.0000.rib... it then executes a command such as "prman rendering.000.rib". the command prman works OUTSIDE of maya, it stands alone outside of maya. That is the way the MOST people use standalone rendering.

 

If the rendering was a plugin it would have its core based on the the SDK of the 3D package. As a standalone, it does not rely on the SDK of the program. It is, well, a standalone. What it does not have is a GUI (graphics users interace). Artlantis made its own GUI. mtor (and what I suspect vray will do) is to save the user a step of importing the file into another package, and translates the important data directly to its own file format. That way the user doe not have to worry about complex character setups, transfering UV's, etc... While as a user, Artlantis seems more of a standalone package to you, prman, mentalray and the future vray are also standalones... they will just be more production and user friendly, by giving GUIs inside the 3D package.

[GaryR50]

Chris, the very fact that the program must communicate with another program in some way is what prevents it from being a true "stand-alone" renderer. Artlantis does no such thing. You can import a model file to it at any time without the need for any other software interacting with it. This is how I define a "stand-alone" anything. "Stand-alone" means exactly what it implies: complete independence.

 

Gary

[Christopher Nichols]

This is very funny... because Artlantis a very widely used renderer (NOT), depends on other programs for it to work. You need to import the model into it from ANOTHER program. Thus making it very dependent and not at all independent. Now let me ask you this. How do you plan on translating character animation into artlantis? What about dynamics? What file format would you use for that?

 

There are two things that are clear. First, I will never convince you something that is very obvious to anyone that makes a living in the rendering world, and second, you are way behind the times if you are still mentioning things like artlantis.

[mauarduz]

I've read through this thread, and i catch lotsa new technicall terms and concepts, i might be dumb, but i dont see the benefits of the "stand alone" concept as explained by Mr. Nichols, as a user and not an expert it is easyer to understand "stand alone" as Mr. GaryR50 conceives it.

 

where lies the price difference ?

where lies the performance difference ?

 

Mr. Nichols, if you could help me understand these concepts please.

 

thank you

[Christopher Nichols]

Ok... I will try to be a little more clear on this.

 

First let me explain where I am coming from so that you have a better

understanding of who I am. I am an ex-architect that now works in the Visual Effect Industry. I currently work as a lead lighter at a company called Digital Domain which has done work on such movies as Titanic, etc... So this is what I do for a living.

 

 

Lets first define some terms:

 

Submitting a render means that you have set some settings and hit some button that says you want your (or someone else's computer) to render an image.

 

The SDK means the source development kit. A program such as 3d studio has a source development kit. If you write a plugin for max you need to use its SDK. This means that your plugin needs to rely on the libraries (dll files and exe files) of that 3D package.

 

GUI means graphics user interface. A program does not need a GUI to run, a GUI is only needed for the user to interact with the program.

 

Shaders... these are definitions of materials, lights, effects, etc...

materials are usually defined by BRDF (Blinn, Lambert, etc...) combined with other properties. Lights are a volumes of intensity of and colors. Effects are usually used for things like clouds, hair, and other random stuff.

 

A shading language is a computer language which can be used to define shaders. For example, a standard of the industry is RIB which is most commonly used by Renderman.

 

The Frame Buffer is the window that displays your rendering. When you have submitted your rendering, the rendering engine can spit back the segments of the image that it has rendered back.

 

Animation is when things move and change over time. Most architectural animation is very dull only moving the camera. However, 99.9% of animation usually involves much more than moving cameras. In involves character animation, particle systems, hard and soft body dynamics, fluid simulation, etc...

 

Pipeline: the method from which you start to deliver. For example, if you are going to do a shot, you need to model, you paint textures for it, the model then goes through an animation process, at which point it goes through a shader process, then a lighting process, followed by a rendering, then compositing, then editing, etc... that whole process of how the data flows and is transfered from one stage to the next is called the pipeline.

 

Anyway, let us divide our rendering into three categories based on what is in the thread so far. A plugin rendering, a standalone rendering (ands its

traditional pipeline), and a standalone rendering with its own GUI.

 

Let's talk about the rendering engines:

 

A Plugin rendering engine...

 

Basically, this engine is tied to the SDK of the 3D package that it is designed for. It relies completely on the 3D package for its part of the pipeline.

 

 

The good:

- It is easier to write than a standalone since a lot of the core sdk is being

used via the 3D package.

- Things such as the VFB, the basic shaders, the 3D interface, can all be used within the 3D package. Why reinvent the wheel? A blinn shader is a blinn shader as defined by Jerry Blinn. How it may look in each rendering engine may vary, but it has a standard mathematical definition in its BRDF.

- Since it lives within the 3D package, the pipeline is simple since it gets its 3D data directly from the 3D package. This means that when doing an animation is seamlessly transfers 3D data for every frame to the rendering including the motion vector in case any motion blur is needed.

- The SDKs of most 3D package support custom shaders for specialty reasons such as optimization of raytracing, the custom effects. So the rendering engine can write custom shaders within the 3D package even if it is a plugin.

- Most other plugins that live inside the 3D package will work, or, the

rendering engine can usually easily be changed to allow them to work, since the data type all lives inside the 3D package.

 

 

The bad:

- It is completely dependent on the 3D package. In order to make it work in another 3D package, you would have to rewrite it completely. The current BIG disadvantage of Vray and why everyone wants a standalone.

- Anything that is sucky about the SDK from the 3D package that is being used by the rendering engine will get carried across.

- Has to be rewritten every time the 3D package gets upgraded.

- When rendering, it needs to sit inside the 3D package. For interactive

rendering, that is all fine and good, but when network rendering, you are

carring the whole 3D package when all you want is the rendering part.

 

A standalone rendering engine with a traditional pipeline...

 

This rendering engine stands alone and is built on its own SDK. It's core lies outside the 3D package. The way that it renders an image is usually

via a command as I mentioned in a previous post. Generally the pipeline relies on a method to transfer the 3D data to the rendering engine. This is traditionally done with a plugin which does everthing SHORT of rendering. The plugin gives the user an interface and a general front end to the rendering WITHIN the 3D package.

 

The good:

- The front end plugin for the rendering are usually easy to do. The front end does not render. All it does is take the 3D data and shader data and creates a file that is run by the rendering engine externally. Basically it is a super fancy file translater. File translators are a pretty easy plugin to write so that is why high end rendering engine have different front ends written by different companies. Large effects companies sometimes write their won front ends.

- Since the front end is easy to write, it is easy to write one for

different 3D packages. Just like writing an "obj" importer for MAX and MAYA, it would be easier to write a front end to Vray for MAX and MAYA if the core of Vray was outside of the 3D package.

- Since the front end is within the 3D package, it has all the pipeline

advantage of the plugin rendering with the possible exception being compatible with some plugins (transfer the plugin data into a format like RIB can be tricker.) But it can still use a VFB within the 3D package, use the Material editor withing the 3D package, have its own shaders, transfer ALL animation data accurately.

- Only the front end is dependent on the 3D package, once the data is sent to the rendering engine, it can use its own super optimized programing.

- Everytime the 3D package changes, you only have to rewrite the front end.

- when network rendering you only need to carry the rendering and not have to carry the whole 3D package

 

The bad:

- You now have a slight delay (depending on how good your front end is) when submitting your render. It now translates that data to a file which is then submitted to the rendering engine.

- It takes a long time to write a standalone rendering engine since you have to write all aspects of it and are not able to rely on any part of the SDK from the 3D package.

- The author of the rendering engine has to define a shader language and deliver and SDK for developers to write their own shaders.

 

 

A standalone rendering engine with its own pipeline and GUI...

 

You can look at this several ways. The main way to look at it is like a

standalone rendering engine with a 3D interface that sits completely outside the 3D package. However, if you think about it, the only thing that you are getting form the other 3D package is the model. Way back in the day, I remember a lot of people transferring their 3D data from FormZ and rendering it in 3D studio. This is sort of the same thing. So you can think of this type of rendering engine as yet other 3D package that only renders.

 

The good:

- It does not rely on any of the previous packages SDK so it can be optimized for speed... same as the traditional standalone.

- Since all it needs is a model file, as long as it can read a model file form

other 3D package, you are good to go, one front end for all.

- Who cares if the 3D package is upgraded, as long as you can write the model file you are fine.

 

The bad:

- You have to learn yet another 3D package.

- The author has to write EVERYTHINGS including the GUI, Open GL interface, etc... basically like writing a 3D package.

- Forget about doing animation... animation data does not transfer easily from one 3D package to the other. Transferring UV data us hard enough, animation, especially more complex animation such as Character animation, is VERY hard to transfer and usually a real hassle.

- No plugins from the 3D package will work at all, since it is a different program.

- everytime I need to make a change to the model, I need to open the model in another package, translate it to a model format that the "rendering program" can understand, open it in that package, reapply the UV's if they did not transfer, assign the the shaders to the new model AGAIN, and render. In the other two methods, all the 3D data gets sent to the rendering engine at the last step through an automated process, so any model and animation changes are no problem.

 

 

Anyaway, hopefully that gives you all the information you need.

 

You'd think I was not busy, but the truth is I spent a great portion of the day waiting on RIB gens so between submits, I was writing the fun little post.

[GaryR50]

This is very funny... because Artlantis a very widely used renderer (NOT), depends on other programs for it to work. You need to import the model into it from ANOTHER program. Thus making it very dependent and not at all independent. Now let me ask you this. How do you plan on translating character animation into artlantis? What about dynamics? What file format would you use for that?

 

There are two things that are clear. First, I will never convince you something that is very obvious to anyone that makes a living in the rendering world, and second, you are way behind the times if you are still mentioning things like artlantis.

 

You're still not getting it, Chris. What I mean is that it doesn't require a symbiotic relationship with another application in order to function. Artlantis is not a plugin, as V-Ray is. V-Ray won't function at all on it's own, Artlantis will. Of course you have to import a model to Artlantis. It's a renderer, not a modeler. V-Ray won't even render a model file, unless you're using MAX.

 

Who said anything about character animation, or animation of any sort? All I want is a global illumination renderer for my architectural models. Why is it like pulling teeth to find ONE that can import a DXF or 3DS or OBJ and render it? Artlantis does, though not to the same level of lighting simulation. Reals does. Hell, even Bryce 5 can do it. What's the big mystery about appying materials and GI lighting simulation to a model file that is in a standard model file format?

 

I think I see why people in the CGI world don't have a clue about what is happening in architectural visualization. They think rendering is all about creating special effects for movies. Not everyone cares about character animation, you know.

[Christopher Nichols]

Ok... I will try to put it in your terms. The standalone version of vray will function outside of max. It will render a vray file. The vray file will be created within max. It does not run within MAX, a program within max will run a program outside of max which will render the file that was created inside of max.

 

OK now think about this... imagine you could render travel back to the mid 90's and use artlantis or bryce. Image you could render your obj file directly without having to open artlantis. Where you simply right click on the obj file for example and select a command like "render to artlantis." The only way that would work is if the obj file had all the camera information, shader information etc... so what if you could add all that crap inside your 3d package and then save that inside your obj file so you don't have to do it every time you open, it would save you some time... that is the basic idea behind the the pipeline I illustrated.

 

BTW I have a a REAL clue what is going on inside of architecture illustration. Considering the fact that I was doing it professionally from 1993 to 2002...

 

If you don't see the advantages of a the traditional standalone rendering pipeline as I illustrated, I'm afraid I can't help you. I think you may not be seeing the forest for the trees. Sorta like the people that insist on using FormZ for modeling Architecture because they think that Boolean modeling is the only way to work.

 

Or, if you could explain to me why the artlantis pipeline has an advantage OVER the traditional standalone method, I would love to be informed.

 

BTW architectural rendering has had a great deal of influence on CGFX, mostly since it way ahead of the curve in terms of GI.

 

 

You're still not getting it, Chris. What I mean is that it doesn't require a symbiotic relationship with another application in order to function. Artlantis is not a plugin, as V-Ray is. V-Ray won't function at all on it's own, Artlantis will. Of course you have to import a model to Artlantis. It's a renderer, not a modeler. V-Ray won't even render a model file, unless you're using MAX.

 

Who said anything about character animation, or animation of any sort? All I want is a global illumination renderer for my architectural models. Why is it like pulling teeth to find ONE that can import a DXF or 3DS or OBJ and render it? Artlantis does, though not to the same level of lighting simulation. Reals does. Hell, even Bryce 5 can do it. What's the big mystery about appying materials and GI lighting simulation to a model file that is in a standard model file format?

 

I think I see why people in the CGI world don't have a clue about what is happening in architectural visualization. They think rendering is all about creating special effects for movies. Not everyone cares about character animation, you know.