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
