To refine a bit more:
Isn´t it about time mR is treated like any other 3rd party
renderer? Including the way it´s integrated into the xSI GUI?
This would mean there´s no mimiking of mR functionality
required to break into XSI but instead one can be sure
to get a fully functional 3rd party renderer that uses
it´s own mindset and tools, integrated based solely on
the dependencies this specific renderer has and the
one or two XSI specific implementations, like passes
that have evolved from a rendering tool to an organization
tool thanks to partitions for some?
This would also include the XSI menues.
From what I´ve seen sofar in the way mR was integrated
into Maya or 3rd party integrated into XSI and Maya,
the most time wasted was with trying to copy existing
functionality up to the point of favouring compatibility
over unique feature set, like when Maya nodes had to be
made working with mR for several versions while many of
mR´s native functionality still isn´t exposed nicely in Maya.
One got all the Maya "crap" nodes but no nice, fully functional
mR nodes without jumping through hoops. Even today, many of
the quite useful mR nodes need expert knowledge to even be
found hidden somewhere in the Maya interface but then still
usually lack exposure of basic parameters.
In a way, 3rd party renderer seem to even copy that way
mR was implemented in Maya, or in regards to XSI, seem to
accept the fact that mR is so prominent in the XSI GUI.
To hell with that.
If I want an alternative, I must ask for a completely
selfcontained solution bold enough to have it´s own
way of problem solving instead of expecting that to
work fine with mR!
Maybe, it would also help to get more innovation from mR
if a simple toggle removes mR completely from the XSI GUI...
Cheers
tim
Tim Leydecker 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
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
