|
MR doesn't have its own very specific way of handling the general principles of shaders.
It's perfectly reasonable and possible to expect a conversion of many, if not most, nodes that aren't the monolithic blocks like architectural etc, and since XSI comes with libraries of these shaders that people are used to it's also expected that they can keep shading things the same way.
The rendertree is nothing but a way to graphically program, same as you would do in SL In RMan, and tons of things react the same way in MRay (once you know the specifics) as they would in another engine.
All these engines can also add their own nodes.
On Tue, May 6, 2008 at 11:28 AM, Tim Leydecker < baueroink(at)gmx.de> wrote:
I wonder why people would insist so much on translation
of mR functionality and shaders into a 3rd party renderer?
mR has it´s own, very specific way of handling things,
especially when it comes to raytracing, in general,
it´s sort of object centric and material shader based.
Requesting a 3rd-party renderengine to fully support the
mR way of organization, including the quirks would just
be restricting maybe up to the point that the unique
3rd party implementation/renderer becomes useless?
If at all, I´d also prefer first to have a switch in the
Material node, labeled "rendererXY" where I could plug
my 3rd party shading network and skip any "mR-phong"
translation - if it´s just translated, why bother with it.
Isn´t it one asked for a 3rd party type shader better than mR phong?
Now one could call this request destructive but in fact
it is just focused on being legacy free, for dependencies
or quirks not even contained in the 3rd party code but mR´s.
Cheers
tim
Alan Jones wrote:
On Mon, May 5, 2008 at 11:19 PM, Raffaele Fragapane
<raffsxsilist(at)googlemail.com> wrote:
As far as I know at present time those plugins that convert the rendertree
do so internally. That means that the same companies could provide you with
a mixer node to use downstream that always simply reads one channel in MRay,
but internally is converted by the rendering engine to read and convert a
different tree.
While somewhat gimmicky it's fairly trivial to implement and could be
daisychained without problems to accomodate a more than two ways switch...
Or I might be talking out of my ass.
No - that's usually more muffled - this is definitely an easy one to
do with the current renderer
api.
Cheers,
Alan.
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
|
