Maxwell and Renderers in general...

[Eugen Sares]

Ok, doing some research where are we heading in the rendering department.

Maxwell 2.5 is out. General opinion of the past years was more or less:
forget it, too slow.
Yet, at closer look, I must say: don't believe the hype! This is a
fantastic renderer!

Interior scenes: no problem.

Multilight: Tweak intensity and brightness of light emitters after the
rendering is finished. Cool!!!

Resume render. Who else can do this?

Simple setup! More or less the only parameter is Sampling level.

It's not only about rendertimes, but also setup time.
Had a lot of "fun" already tweaking abstract settings in mental ray or
vray to squeeze out a decent image. 100 testrenderings until you are
ready to go? Especially with stills, you might be better off simply
letting Maxwell render a little longer and worry about something more
interesting like the picture itself.

So far, so good... but
SI's Render Region is not supported.
A-ha, there's "Maxwell Fire":
http://www.maxwellrender.com/fire/index.php

Wow, exactly what we need!!
Realtime preview, perfect renderings... how long have we been waiting
for this??

BUT: the Softimage plugin does not support Fire either!
Why??? max and Maya's do, why not Softimage?

Here's what Mihnea Balta in the Maxwell Forum says to this:

" From a workflow point of view, integrating FIRE makes sense when
there's a
built-in material editor. In Softimage we use referenced materials because
the UI toolkit is too limited to support the complex structure of the
Maxwell material. In this case, since materials are edited with MXED, we
can't update the FIRE window while you're tweaking a material. You would
have to click edit, make a change and close MXED to see the change in
FIRE, and that's hardly interactive.

We could probably build a material editor and embed it in Softimage using
the platform UI API (Windows API, basically, since we don't support the
plug-in on Linux anyway), but it would be quite a bit of work. However,
we've taken a look at the event system in Softimage, and it's not good
enough to support an interactive renderer. It's not even possible to be
notified in a reliable way when an object gets deleted.

Given all this, we've decided we won't support FIRE in Softimage.

...

Arnold's materials are shading networks composed of nodes with relatively
simple attributes and UI, so that's easy to integrate in Softimage. Since
they are made of XSI nodes, it's possible to track changes to them and
update the preview render. I'm still curious how they handle geometry
modifications and object removal, since those are not shown in the video
(my guess is that they don't). We had a prototype FIRE implementation in
XSI, but we dropped it after we saw how many things are broken, badly
designed or don't exist at all in the relevant APIs. The only thing which
worked more or less was moving the camera around, but even that's
difficult to do if you group the camera with something and move the group.

Maxwell has a single, monolithic material with lots of functionality, so
it requires a more complex UI. We could split it into nodes (actually,
that's how it's implemented in Maya and Max behind the scenes, but with a
custom UI on top to hide it), but editing a material would be considerably
more difficult than it is in MXED. For example, in order to add a layer,
you would have to create a layer node, create a BSDF node, and connect
them to the correct slots. Moving a layer from the bottom of the stack to
the top is a simple drag'n'drop operation in MXED, but would mean
disconnecting all the layers and reconnecting them in the correct order in
a network-based implementation. I think we would end up with something too
clumsy to be useful. Skipping the Softimage SDK entirely and building our
own editor window is most likely possible, but as I said, it takes some
work, and I don't know when/if we will have time to do it.
"

Anything official to say to raise our spirits?
Best,
Eugen

[Guillaume Laferriere]

Well, if they split the big monolithic material into nodes already for Max, and Maya. I don't see why they can't do it for Soft. What's important is to rely on the shader nodes to hold the data.
The Soft Renderer API do support a dirty list system that is specific to rendering and separated from the more general event plugin system.

I think they just did not try hard enough. I don't remember receiving questions from them since XSI 7. And remember that XSI 6 was the first version with a real render API. It had it's limitation for sure.

They are right in saying that our UI API is missing some bits, but still they can work around it by doing a native window, use PyQT or create a custom display host.

Guillaume Laferriere

[Steven Caron]

ya there is no reason they couldn't have had a better integration. i have worked with the softimage rendering api and it has what they need to support the render region and has since day one.

it just comes down to the market, if there were thousands of complaints from customer's using the softimage plugin, then things would be different.

s

[oktawu]

haha, Mihnea Balta and his love for softimage.

i know Mihnea well, even lived in the same apartment at one point.

been on the maxwell for xsi beta some years ago, and let me tell u,

he just takes the flaws in the xsi api a bit too much to the heart :)

i admit, he's not the only one...but him, i know personally.

u want to torture the guy, just make him implement something for

the platform, hehe. he'd rather write 1000 maya plugins...in a week,

using a japanese keyboard, handcuffed to an empty refrigerator. 

just don't tell him i said that....cuz he knows it true.

--

okto | visual

www.okto.ro

[Steven Caron]

it sounds like he just hasn't had the time/resources to invest in the plugin to improve the integration. not having render region support with or without "FIRE" support is just silly.

s

[oktawu]

to his credit, he's an amazing programmer, and a very resourceful one.

so whatever the reasons behind his pov, they are probably well grounded.

last year at the end of my vray for xsi beta, i had the chance to speak with

peter mitev, chaos group ceo, at a small vray conference, and he pretty

much complained along the same lines. now i'm not that programming savvy

to know if it was the exact same thing, but he basically said, the rendering

api was lacking, and the everchanging, sometimes poorly documented sdk,

makes the dev team stall, and forces them to redo work they shouldn't have to.

who knows, i'm sure if the solidangle guys got arnold up and running,

anything is possible. there is also the business side of things, sure , but i can't help notice

the strange fact that it is usually the independent teams that develop tools for xsi. 

every other attempt from established companies usually ends up vaporware. 

(ex. ravix, blastcode, final render, vray). and yeah, i know the vray beta is still going on, 

last i checked the ftps it was in active development, but it's moving at the pace of a slug.

--

okto | visual

www.okto.ro

[Steven Caron]

"to his credit, he's an amazing programmer, and a very resourceful one.

so whatever the reasons behind his pov, they are probably well grounded."

i agree totally, this is why i think its about having the time/resources to improve it. like i said, if thousands of angry softimage customers bought the product the state of the plugin would surely be different.

i am of the opinion that developers coming from the 3dsmax background are always going to complain about the API not being open enough. its also my opinion that what softimage provides is quite easy to use and get up and running in a reasonable time. the changes happening to softimage are surely improvements and if the developers stuck with it and reported problems to the softimage they could achieve the integration they so desire.

a friend of mine had a go at integrating maxwell into softimage, before the rendering API was available. if then we were sending data to maxwell from softimage in a couple hours. i wonder if the SDK is still available to customers? then a 3rd party could integrate maxwell

s

[Javier Vega]

Well... here there are an angry softimage customer because the plugin dont have the FIRE yet.  What can we do?

2011/1/18 Steven Caron <car...@gmail.com>

--
Javier Vega

www.zao3d.com

móvil: 616 64 73 57
08922-Santa Coloma de Gramenet
(Barcelona)

[Steven Caron]

"...if thousands of angry softimage customers..."

organize and flood them with complaints...? FIRE or not, i would have been complaining years ago for not supporting the render region.

[Eugen Sares]

oktawu, could you use your good contact to Minea to maybe rethink his
attitude about Fire?

There are more render options than I thought:

mental ray (of course. iray upcoming??)
Arnold (beta, fast)
Maxwell
VRay (beta, slow)
3Delight
Indigo
Fryrender
Arion
Octane
LuxRender
TheaRender (interesting! You wrote the plugin, Steven?)
finalRender (beta seems to be stalled.)

The more, the merrier, but only with Render Region support and interactive
preview things get really 21st century, second decade!
Softimage should open up the render API doors as wide as possible for 3rd
party developers, and communicate this ambition.
Looks like there's some work to do, see the Arnold hotfix.
If Softimage and Nextlimit are just waiting for the next move of the other
side, noone wins!
Cooperation??

Am 19.01.2011, 20:13 Uhr, schrieb Steven Caron <car...@gmail.com>:

> "...if *thousands* of angry softimage customers..."

[Steven Caron]

"Softimage should open up the render API doors as wide as possible for 3rd party developers"

i believe mental ray is reimplemented on top of the rendering API provided, halfdan and guillaume would need chime in if that isn't true, so there still is no excuse for nextlimit. yes the material editor is indeed an issue but since they already have a standalone material editor (MXED?) they should use the CDH to host it and have the changes pump through the CDH events into softimage scene data then into the maxwell FIRE renderer. (you open a floating or embedded CDH set to the maxwell material editor, the changes you make to the gui map to the component nodes minea mentions in his response, those changes are picked up in the renderer plugin dirty list.

about the TheaRender plugin, Thea doesn't have a c++ api to connect to the rendering api, so the plugin is a simple xml exporter really. i develop it on my free time and make little to no money from it. because of that there is very little incentive for me develop for it fulltime. if that was different and there was a lot of money coming in i wouldn't let a gui issue stop me from releasing or including a feature paying customers want to use.

s

[Vladimir Koylazov]

> i believe mental ray is reimplemented on top of the rendering API provided

Doesn't look like it, unfortunately. We have come across pieces of
information that we need from XSI to match the results from mental ray
where the answer from ADN was "we use a different internal API for
mental ray and there is no way to get this data".

Best regards,
Vlado

[Steven Caron]

;(

[Stefan Kubicek]

What you describe is symptomatic for many parts of the Softimage SDK unfortunately, and has bitten me and many others in the arse in other situations too, though on more simple tasks than implementing a renderer.
E.g. some UI features are black-boxed and not exposed through the SDK (in general, methods to configure menus and RC-Menus on the fly are missing entirely, except adding menu items through self installing plugins, which is not enough by far ), or how to display a checkmark next to a menu item, how to add a menu item to the edit menu, no way of reliably getting the floating window object currently under the mouse in a reliably aand easy way, no object level exposure of the painting tools, etc, etc...
I know I'm repeating myself here for the upteenth time, please bear with me.

--
-------------------------------------------
Stefan Kubicek Co-founder
-------------------------------------------
keyvis digital imagery
1050 Vienna Wehrgasse 9 Austria
Phone: +43/699/12614231
--- www.keyvis.at ste...@keyvis.at ---

-- This email and its attachments are
--confidential and for the recipient only--

[Eugen Sares]

Vlado,
great to see that you are still around here with the SI folks!!!
Do I understand you right: VRay for Softimage development slowed down
because of SI render API weaknesses?
At Rusko Ruskov's presentation in Siegen/Germany October 2009, the Render
Region was already working.
So what's holding you up from making this fantastic renderer available for
this fantastic host app?
Best,
Eugen

[Vladimir Koylazov]

> Do I understand you right: VRay for Softimage development slowed down
> because of SI render API weaknesses?

The new API changes caused us a lot of headaches as many things broke
and had to be fixed. But on the other hand, those changes were done to
make our job easier for the future, so I'm not complaining :-). Other
than that, integrating a renderer (to the extent that we want anyway) is
simply a tedious job and takes its time.

> So what's holding you up from making this fantastic renderer available
> for this fantastic host app?

Nothing much at this point, I guess. There are some little bits and
pieces that are still missing, but they will be done soon.

Best regards,
Vlado

[Eugen Sares]

Thanks for the answer! Fantastic!!

With your effort you will definitely attract a good chunk of the archvis
crowd (which is huge) away from max to Softimage.

I know the resentments from Softimage officials about this chapter, though
I don't really understand them.
How does "box business" (archvis) interfere in any way with the ambitions
towards high-end simulation/effects/character anim?
Actually, everything you really need for archvis can be useful for
projects more on the "top-notch" side:
good modelling features (check) and a modern renderer (mental ray: no
check).

When Vray for SI is out, for me as an allrounder there won't be one reason
left to touch 3ds max for anything except data exchange...
Best,
Eugen

[Marc-Andre Carbonneau]

You forget about the UNITS "issue". Every Softimage users know that Softimage units can be anything but the archviz crowd want real units.
;)

-----Original Message-----
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Eugen Sares

[Steffen Dünner]

...not only the archviz crowd! ;)

2011/1/20 Marc-Andre Carbonneau <marc-andre...@ubisoft.com>

--
PGP-ID(RSA): 0xCCE2E989 / 0xE045734C CCE2E989
Fingerprint: 394B 3DA9 9A9A 96C6  3A5A 0595 EF92 EE1F

[Stefan Kubicek]

I would say it would attract a fairly large crowd of all kinds of people, not just those interested in architectural visualisation.
Hence the huge interest in Arnold too. After all, what good is a DCC package if you can't make nice looking images with it?

[Stefan Kubicek]

I've done a fair amount of ArchViz in my life and I can tell you I could not care less about units.
In fact, units have caused me more trouble than they did good in Max. Everything's so much simpler without them.

[Eugen Sares]

Scr*w those friggin' units...
.'}

Am 20.01.2011, 16:20 Uhr, schrieb Marc-Andre Carbonneau
<marc-andre...@ubisoft.com>:

[Marc-Andre Carbonneau]

Hey man I don't really care I've been using Softimage for 14 years, never bothered me. I'm just repeating what we usually read from archviz people on this list. ;)

[Guillaume Laforge]

I always found the name "archViz" rather strange. So if I build a cg horse, am I a horseViz artist ? If I model a tree, am I a treeViz one (etc...) ?

:)

Guillaume

[Marc-Andre Carbonneau]

No you'll always be a frenchViz living in Montreal. ;)

[Guillaume Laforge]

Ah ah, I think I'm going to copyright "frenchViz" right now !

:)

[Gene Crucean]

Hahaha.

On a serious note. Why has the SDK been such an issue for so long? There has to be logic behind it right?

--
[Gene Crucean] - [VFX & CG Supervisor/Generalist]
** Freelance for hire **

[Steven Caron]

i dont know about you but i see improvements... they did add the rendering api because people had issue with it, and people complained about shader development/api and they updated that too. people complained about particles and look what we got. i just think it takes longer than we like to get these improvements, so in the interim we bitch incessantly.

[Gene Crucean]

Oh yeah, for sure. And I like the direction things are going. Sorry about not being clear.

But we still hear quite a few complaints in this department. I'm sure it takes a while to open things up properly, but I guess I was mainly interested to hear if AD had any sort of logic behind it.

[Guillaume Laforge]

>On a serious note. Why has the SDK been such an issue for so long? There has to be logic behind it right?

Speaking only for the rendering part of the SDK (as it was the initial subject of this thread), I really don't think that there is a major issue now.
My only experience in this area was when I was an active beta tester of SitoA, the Arnold plugin for Softimage. I also contributed in the development of things like the support for the XSINormal shader, the Standins, etc...
The Rendering SDK was looking good to me. And before that, a plugin was developed for a TV serie (Pokoyo) using the old Softimage API (I can imagine the pain at this time) ! So I guess, the issue is not 100% completely in the Softimage SDK camp.

I think that Solid Angle developers (the Arnold company) are really working hard to integrate as many feature as they can in their Softimage plugin. It is not a little task to implement every rendering feature of a 3D application. On top of that, the 3D application always evolve and can add more features to implement in the rendering plugin (like support for rendering Strands when ICE was released...).

frenchViz

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Gene Crucean
Sent: Thursday, January 20, 2011 2:31 PM
To: soft...@listproc.autodesk.com
Subject: Re: Maxwell and Renderers in general...

Hahaha.

On a serious note. Why has the SDK been such an issue for so long? There has to be logic behind it right?

:)

:)

Guillaume

<marc-andre...@ubisoft.com<mailto:marc-andre...@ubisoft.com>>:

> <vl...@chaosgroup.com<mailto:vl...@chaosgroup.com>>:

>>> <vl...@chaosgroup.com<mailto:vl...@chaosgroup.com>>:

[Eugen Sares]

Back to topic: Maxwell.
A potential showstopper is the missing support for hair/fur/grass etc.

Tried hair instancing, but even then the hair is generated at rendertime,
which of course does not work either.
Is it possible to make an (animated) geometry "snapshot" of hair, to bring
it over to Maxwell brute-force?