Arch-viz addons for Softimage?

[Eugen]

MoI: nice idea, but before any 3rd party developer can provide anything watertight when it comes to curves/surfaces, the SDK needs to provide all the necessities.
ICE modeling also still needs support for curves and surfaces, it cannot be used as a workaround for now.

Unfortunately, the Softimage SDK is more restrictive as, say, 3ds Max's. You cannot add new geometry base classes here. In Max, you can, also in Maya afaik.

[ActionArt]

That's really sad. Such a shame the SDK is limiting work like this so badly. If the pace of development with the new team continues as is I don't suppose there is much hope for improvement.

[Eugen]

I sincerely doubt, you'll get Autodesk to change much in that respect anymore, unless you get full backing from the people that got "SOFT-9089" fixed so quickly...

Yeah... among the heavyweights, Matt Lind for example is pushing for those SDK fixes, too.
Still nothing.
But what should we do? Give up on this completely? It would simply mean we will always have to depend on the good will of the AD devs for decent modeling tools, because if there's no complete SDK support, there's nothing you can do, or use sorry hacks. And you know how much emphasis is put on the modeling toolset - not much, besides the few ICE based poly modeling tools.

In other words, if this does not get fixed, Softimage will remain third choice regarding arch/design visualization. A damn shame, and actually a really stupid marketing decision, because a huge part of the SI userbase are freelancers, and they tend to deal with visualization a lot.

The irony is that this cluster update mechanism is in place internally, and also in ICE. How difficult can it be to implement it in the SDK (both C++ and scripting)?


Edit: this SDK debate is going on for years now. Luc-Eric once stated, that you need to be a Softimage architect to be able to handle this.
I don't really think so. Provided with a good code example, it must be possible, and curves are a relatively simple kind of geometry to deal with.
Surfaces of course are much more demanding, but if the door is open basically, someone will go through it in time.

[Hirazi Blue]

I agree it seems a "lost cause"...
I was very surprised when they didn't at least introduce some ICE Curves,
although even those wouldn't probably even begin to "cover it".

[Eugen]

Maybe we should start one of those online petitions like this, which was a success:
http://www.change.org/en-AU/petitions/w ... age_notice

...and nag the hell out of them.

[ActionArt]

Wouldn't hurt to try I guess

[Daniel Brassard]

http://www.opennurbs.org/

http://blog.rhino3d.com/2011/01/rhino-s ... ource.html

http://graphics.pixar.com/opensubdiv/

Can OperNURBS and OpenSubdiv be ported to Soft?

What does it take? What are the obstacles?

[luceric]

dude, unrelated reply? If all you wanted to do was model the nurbs and import them into soft, IGES should work for that. adding another SDK doesn't change a thing to what was being discussed here. and opensubdiv is off-topic.

[Daniel Brassard]

The Dude abides!

[ActionArt]

Dude! (as in Luceric). I think you might have missed the point altogether. I think what Dan was trying to do is come up with ideas for an INTEGRATED solution. Sure, we already have MoI and a many other curve modelers which are fantastic and they export whatever you want. The problem (at least for us freelancers or small shops) is this...we model a nice model in MoI. We import to SI. Then we start texturing, rigging, animating or whatever and then...oh crap...we have to change the model for whatever reason. Back to MoI, then re-do, re-do....you get the idea. So an external modeler will never be a great solution, ever.

It seems (I'll have to take their word for it) that the SDK as it is has some major roadblocks to creating such tools in SI.

Dan has a valid question in can some other form of Nurbs (OpenNurbs or whatever and yes OpenSubs would be nice too) be somehow brought into SI in some form or another and work in an integrated way? Us users don't really care how it just a matter of finding a way.

I'm no help in that area at all but maybe someone will come up with a cool idea. ;)

[luceric]

... but OpenNURBS is not a nurbs modeling library, it's a library to read and write files and that doesn't fix anything.

[ActionArt]

I see. So is there anything that might work?

[Eugen]

To make it as clear as possible what the actual problem is, here are two screenshots.
It's a comparison between how clusters are handled when factory operators (bevel) or custom operators (offset subcurve) change the topology.

One important thing to know: ALL topology operators rely on clusters to provide the information which components to process, factory or custom. There's no other way, I looked.
If you like you can create the cluster by hand and apply the operator to it, but if you just apply it to a component selection, as you would normally do, there will be one created automatically, but it will be hidden in the explorer for the reason not to clutter the operator stack.
You can do a simple check with the SDK explorer to see them. Example: xxx.polymsh.cls.Polygon_INTERNAL.


factory operator screenshot:
polygon mesh with 6 (disconnected, doesn't matter) polygons, cluster created with polygons 3 and 4, bevel op on the cluster
2nd column: polygon count changes, yet automagically the bevel op also feeds some index update information into the cluster, so the cluster still contains the correct polygons.
3rd column: deactivated the bevel op, created a cluster from polygon 1, delete component op on that cluster, re-activated the bevel op, and still the clusters remain intact and correct. Clever, actually.


custom operator (SDK) screenshot:
curve list with 6 subcurves, cluster created from subcurve 3 and 4, offset op on the cluster (custom)
2nd column: subcurve count changes, yet because the custom operator cannot update the cluster, it suddenly contains wrong indices.
3rd column: deactivated offset op, deleted subcurve 1 (also custom), re-activated offset op, and nasty things start to happen. The offset op's input cluster is wrong now, and actually I don't fully understand this mess.

Imagine if you pile up a good operator stack and even start re-sorting ops... you will get a mess in no time.
You might get away though if you work in immediate mode, but then you can forget about parametric modeling, which is a very nice thing with curves. That's how Modo and Cinema4D do it... they don't bother at all, and only support a deform stack of sorts.
Houdini is the shining example how to do it right.


Since I don't have any custom topo ops at hand that work on polygon meshes, I used a curve list, but the problem would be the same for custom polygon mesh operators. That's one reason why there are so little custom topology operators available. There not a single example in the SDK help, too.


By the way: there's this other nasty bug in the SDK, so that newly created components are not selectable at first. That's the reason why I use a "Clean Curve" op, because, as all factory ops, it can trigger some internal mechanism to update the selection cache of the object.


Hope you get the point why the SDK needs this update, otherwise we never really get anywhere with custom modeling tools, with the standard SDK at least.
Because, ICE is a different story. Here they try to circumvent the SDK totally, but I must say I dislike this "forking" of concepts, and there are coders/TDs who do not want to use ICE at all for good reasons.
But as we know, curves and surfaces are unsupported yet anyway in ICE, so we are kind of stuck.

Cheers,
Eugen

[Daniel Brassard]

If all you wanted to do was model the nurbs and import them into soft, IGES should work for that. adding another SDK doesn't change a thing to what was being discussed here. and OpenSubdiv is off-topic.

OK, maybe I need to be clearer. The posted links are examples of a "competitor" in the field of architectural visualization on how they opened up their software to CAD/CAM developers. I understand what OpenNURBS does, if the format is already used to import CAD/CAM data and is freely available, then why not tap into that work to expand Softimage capabilities.

Soft offer its own exchange format, DotXSI, but until curve and surface objects are expanded, the format cannot be expanded to offer CAD/CAM developer this alternative. As for DXF/DWF/DWG import from CAD/CAM Software, their has been efforts to create importer, but coming from the same Autodesk family now, why has this import capability not been integrated to the three main 3D apps (or FBX) but that is another story book entirely. In the other hand, that is where ArchViz, Inventor and 3D Max Design, to name a few, come into play and I don't think AD will change that. Softimage does not fit this business model.

That said, Softimage has some quirks, bugs and enhancement sorely needed since v1.0. This has been a recurring request for years, so some attention is needed in this area. Until the core has been corrected and expanded, custom tools and ICE solution will not work as expected.

Then there is the matter of real world units, when you open up to CAD/CAM, real world units of measurements are very important, another area that Softimage has been lacking for years.

I am not for another SDK, but for an update of the current SDK and some enhanced tools that have been lacking for years.

As for OpenSubdiv, point taken but it would be nice to add it as part of the modeling tool set at some point in time.

Sorry for the long rant, the Dude is gone bowling....

[ActionArt]

Eugen, that's a pretty precise post on what the issue is. It should probably be send right to Chis Chia if it hasn't been already. Maybe if it's laid out very clearly like that it would get some attention.

Edit: nevermind, I just did ;)

[Eugen]

Thanks. He should know anyway, because I requested this quite a few times over the last year, as have others.
But no harm in doing it again... ^.^