Vray Scatter

[Oshyan]

You guys probably know about many of the examples I'm talking about. They are generally not as notable as for example Pirates of the Caribbean, more comparable to the limited use of Vue in say Spiderwick Chronicles. But we're also talking about a pre-release product, with 0 marketing (TG2) compared to a product with a few generations of "professional" SKU's, and a fair amount of marketing and evangelism (Vue). We've got some catch up to do, but considering that what we have thus far is entirely organic, I think it's pretty impressive.

- Oshyan

[bobbystahr]

but considering that what we have thus far is entirely organic, I think it's pretty impressive.

- Oshyan

No arguments from me for sure..it's an interesting Journey.. ...

[jo]

Hi latego,

Another problem with movies is that in that field people use Renderman engines, which follow quite a different philosophy from programs like Vue (or TG). You create, rig and animate meshes with apps like Maya/XSI/Lightwave etc, then export the results to a format which can be digested by these engines and render. Shaders are not a graph of nodes... they are actual programs, written in Renderman Shading Language (now you know what that .rsl file extension means) which describe how to compute the resulting image.

Shaders are not that different in TG2, you're just viewing them differently. When you create something with the function nodes (and other nodes, but particularly with function nodes) you are basically graphically programming the shaders. The difference is that the node network is visual programming as opposed to having to type them. There are also visual shader programming tools for Renderman, Pixar have Slim for example:

https://renderman.pixar.com/products/tools/slim.html

I've implemented a few RenderMan shaders in TG2 using function nodes. Nothing fancy, just brick patterns and stuff like that.

When we are able to add scripting support ( or an SDK! ) to TG2 you'll be able to write shaders in a text editor too, just like a RenderMan shader. Each approach has it's benefits. Visual programming is great for getting rapid feedback and prototyping shaders. When I was writing WaterWorks for TG v0.9 I was hanging out for some sort of visual programming, especially because I find it helps me to see things. I ended up writing a bunch of Java applets to preview certain functions, to visualise what changes in parameter values would do. With some improvements ( being able to change the origin of shader previews for example ) TG2 will make that even easier. For more complex shaders it can be easier to write them, particularly when you're doing a lot of maths and such. Much quicker to type "c = a + b" rather than set up nodes for it.

The Renderman shader compiler probably ends up turning the shader into something very much like a graph of nodes during compilation anyway ;-).

Just an example: in Vue or TG, antialiasing is nothing more than selecting some rendering options. In Renderman shaders, you have to code by hand the band limited approximations of your shaders in order to prevent moire patterns!

You still have to be careful about aliasing when creating shaders using the function nodes. TG2's antialiasing can cover up a lot of sins, but you'll still get better results if you make some effort to avoid aliasing. Anyway, I'm sure RenderMan renderers all have the same sorts of antialiasing options.

Programming shaders in RenderMan may be more sophisticated but you can do a lot of the same sort of stuff in TG2.

Regards,

Jo

[latego]

Dear jo,
your last post is a checklist of nightmares for E-On ; do what you wrote (an SDK letting people access TG shading innards) and Terragen will be on pair with the best engines around... may be I should really try out TG2 seriously (and not with 10 minutes doodles).

There is a point about visual programming tools (something that came to me when toying with the idea to create the n-th terrain generation app): how to you express a for loop? E.g. I want to sum 6 octaves of perlin noise; I know that you could create 6 perlin noise nodes and the required amount of adders but it is completely unweldy (and when you need 5 or 7 octaves you are back to the starting point). With a programming language of any time it is a trivial task to code compactly this function, but I haven't found a smart way of expressing it compactly with a node representation...

Bye!!!

[jo]

Hi latego,

There is a point about visual programming tools (something that came to me when toying with the idea to create the n-th terrain generation app): how to you express a for loop? E.g. I want to sum 6 octaves of perlin noise; I know that you could create 6 perlin noise nodes and the required amount of adders but it is completely unweldy (and when you need 5 or 7 octaves you are back to the starting point). With a programming language of any time it is a trivial task to code compactly this function, but I haven't found a smart way of expressing it compactly with a node representation...

You're right of course. There are ways around it, and for simpler loops you can unroll them but it does become awkward quickly like you say. Theoretically I don't see why we couldn't have a loop node. Plenty of visual programming languages seem to have them.

Regards,

Jo