Arch-viz addons for Softimage?

[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... ^.^

[Eugen]

Just thinking... given this cluster update mechanism was exposed, what any topology operator would have to do is keep track precisely how component indices shift after the mesh operation. Points, edges, polygons, subcurves, knots, ....
Some index "shifting" table would be needed, for each component/cluster type.

The update callback of the operator is called once for every output port already. As of now, you can connect to a cluster as output, but if you try to change it, you get an "access denied" error.
If access was allowed, this index list would have to be applied to all the clusters affected by the operator in some strict order. Might not be too easy, but after all it already works... internally.
Good code samples and documentation would be needed.


Just guessing, but maybe the devs want to hide these mechanism from foreign eyes, because it would mean exposing "secret"/patented technology/trickery...
...or maybe they just simply thought too few would ever be interested in writing custom topology operators anyway, and wanted to save themselves the hassle... who knows.

[luceric]

I'm not sure why topo operator sdk has never been done, there really isn't any reason why other than there was other things to do. The lighthouse are pretty much totally satisfied with modeling, in fact they thing it's awesome, they needed stuff in the UV editor, tools to transfer maps, that sort of things, import/export, animation stuff, etc.

IMHO, if these plug-ins can be written for apps that have no construction history, then one should be able to prototype tools that use scripts (modal dialogs) and combination of the built-in operators to get the job done.

Edit: In fact there is no excuse at all to talk about NURBS and topo op here, since the modo plug-in here is not using NURBS at all. Therefore you should have everything you need with ICE modeling to make that operator

[IslandDreamer]

Always fun to see one's post take on a life of its own...

I definitely would consider paying for quality plugins/addons like this Modo set. In fact, I paid $99 for it. Anything that anticipates what I need to accomplish and turns a complicated, tedious process into a couple of mouse clicks is a godsend, imo.

Besides the automated window generation, I also appreciate this plugin's ability to automate uv mapping. Which leads me to a question I've always wondered: why is it that Softimage's primitives don't generate a default uv map? As far as I know, it's the only major 3d program that requires that extra step for its primitives.