Example, using 3delight should feel similar in terms
of functionality in Maya, Houdini and XSI instead of
asking to have a similar look and feel of mR and 3delight
in XSI by having access to the same set of nodes.
The area besides materials and shaders in general
that shouldn´t be forgotten is lights and shadows.
You already mentioned shadows, mR depthmap shadows
really shouldn´t set the standard everybody else
tries to mimik, nor should the limited set of lights.
It is true, there is common sense about general workflows,
driving the color attribute of a shader with a texture
might be one of those, mixing some inputs in a mathematical
way is definitely also one but everything else might allready
be renderer specific.
Personally, I think all the hassle that Joe Average user
has is that on one hand one wants to stick to learned routine,
on the other hand one urges for something more cool by simply
adding that one node from that other renderer there and be done.
Now imho that leads to crap as it mixes things that don´t belong
together.
Naturally, one should be able to have a scene where one pass
contains 3rd party renderer A and one pass with renderer B
and be able to nicely work organized - which includes no mixing
but makes use of the unique features of each renderer.
The only area that defeats this - aside from the interface -
is the XSI light type implementations.
It´d easily become complicated if you also have to track what
type of light is supported for each renderer and what it´ll
look like. Now asking for compatibility in that area will
result in pretty much the same shoddy look one allready has.
Break connection to mR, you suddenly get simple access to
all sorts and shapes of direct lightsources to choose from,
use different ways of AO, FG, GI, whatever.
So, in conclusion, shadertree per pass, materialswitches
so to say, opening XSI for 3rd party specific lights with
a good viewport representation would be imho the way to go.
It´s also be easier to nail a 3rd party supplier for not having
exposed a simple math node with functionality like add/divide.
Since renderengines don´t pop out of nowhere, wouldn´t it
be really desireable to have benefit of the development
they allready underwent in implementation somewhere else?
Cheers
tim
Frantisek Hradecky wrote:
I also think that way of inheriting properties from mental ray "exclusive"
options (Like aproximation editor, or Shadow options in light properties.)
is not the best way how to integrate new render engines into XSI. It could
be helpful for beginners, but it could pose some restrictions for users that
are already used for example to renderman compliant terminology. I would
prefer to have option to have multiple properties or shader trees for
different renderers hooked on one object. In this way I could follow the
mr-way of doing things and for different passes or element use another
renderer without modifying the same options. Actually this is the way
Affogato works and how 3Delight is integrated to Maya (except for shader
networks). I do agree that for example Softimage base library should be
supported and translated, but for other shaders it should be always prefered
(in my opinion) to not to try emulate options of mr because the mechanics
and results differ. (AO in 3Delight for example).
Francesco.
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
