community ice projects

[fabricio.chamon]

I like the idea of extending the modeling package!

So, as a first step I think we should list the most common tasks and put them into a priority list (according to users vote).

Here's my list (not in any order).

- shell/solidify
- cap holes
- extrusion along curve (2 versions: a)fast and simple, b)complex)
- loft
- revolution
- de-intersect (should fix intersecting groups of polygons: think of fixing the result of a cloth simulation ran without self-collisions)
- symmetry (clone/symmetrize input geometry and copy all its further modifications)
- extended primitives (Eric Cosky alread did a nice set: http://www.boundingboxgames.com/tools/essgeo)
- relax/smooth tool
- retopology (based on curves?)
- merge vertices (based on threshold)
- clone island (clones one or more islands of an input mesh, with option to delete the originals)

so here's what I cant think of right now. I'm not a modeler, so maybe there's much more important things, but hey, it's a start.

I know many of them already exists, but let's make some room for improvements.

[ActionArt]

It's a very good start! Those are all very useful ideas and I think this would be an excellent project.

A couple more ideas:

A good simple extrude polygon that leaves both ends capped.

A good 3D fillet (polygons) like we have with surfaces. I don't know if this is possible as I don't know any package that has it currently.

I would still like to be able to interactively draw primitives properly (see Lightwave).

Those could come as low/last priority.

Anyway, my full support for a modeling toolset as Fabricio has outlined

[gustavoeb]

Nice Fabricio, I would add the aforementioned Modo Bridge Tool, as it seemed to be someones actual need.
I found a video of it but is from modo 202, so I dont know if something has changed in it lately... http://www.luxology.com/training/video.aspx?id=36

Inisheer also suggested that things were to be ranked by ease of coding...

I'll try a little sorting of complexity vs priority then someone with more ICE modelling knowladge can pick it up from there and make a better sorting of things...
I've tried to keep stuff that is already adressed by standard tools down in priority, and stuff that is already addressed byfactory ICE compounds waaaay down

Easy (from highly to less relevant)
extrusion along curve (fast and simple)
Symmetry
Merge vertices (based on threshold)
Revolution
Loft
Shell (ICE version already exists in SAP so is less relevant)

Intermidiate (from highly to less relevant)
Extended primitives
clone island (clones one or more islands of an input mesh, with option to delete the originals)
extrusion along curve (complex)
relax/smooth tool (with shape preservation?)
Cap Holes (ICE version already exists in SAP so is less relevant)

Advanced (from highly to less relevant)
better boolean tools (with actually good results
de-intersect (should fix intersecting groups of polygons: think of fixing the result of a cloth simulation ran without self-collisions. this looks more like a deformer for me, but is great!)
retopology (based on curves?)
Bridge Tool (modo alike, able to twist and find nice solutions to bridge different number of edges)

[Inisheer]

gustavoeb (and others),

Great list. I think I'm going to take a crack at the merge vertices, as that seems to be something I could use quite often.

Is there a preference to the group as to whether we create these as compounds (ie "ICE Programming") or C++ custom nodes? I haven't built any custom tools and I'm not sure if there are any implications / side effects while using one or the other, or if they will both give the same functionality.

[gustavoeb]

C++ ICE developers is a small club, I'm sure ICE compounds will have a much broader audience, but the sky is the limit... I really have no knowladge of C++ and Custom ICE Nodes, but I imagine if you were to do so it would be nice to share the Source or something like that...

[fabricio.chamon]

well, it depends. I prefer to have fast/c++ nodes in my pocket rather than (maybe) not so fast ICE compounds.
If the long term goal is to expand the tools, I think that's the way to go.

In the other hand, the thread name is "Community ICE Projects", which speaks for itself. Having c++ nodes will not help improving others ICE skills.

In the perfect world, there would be one ice version (for study) and one c++ version (for production), but as there are no crazy people over here (well...) that is up to writing two versions of the same tool, this is out of question.

so, in the end my vote is: c++, for those who know c++, and ice for the rest (mere mortals).

[Daniel Brassard]

I like the list so far and would certainly contribute to some projects.

In the other hand, the thread name is "Community ICE Projects", which speaks for itself. Having c++ nodes will not help improving others ICE skills.

I agree, c++ is an advance topic. I would like to see some tutorials with a simple C++ workflow before tackling this subject. Does not mean it cannot be tackled by more advance users, looking to expend there knowledge of ICE to new heights. If the demand is there, I would then suggest we have an area in the community project folders targeted to those willing to share the advance knowledge.

To add to the list: a quick mesher a la ZBrush, one that would paint spheres following the mouse and when you are happy, add the mesher node and all the spheres are polygonized to a quick mesh, ready for detailing.

[Chris_TC]

Do C++ nodes need to be installed? I love regular compounds because I don't have to install plugins or addons. As long as my scene has the compound with its factory nodes inside, it'll work hassle-free. I would hate opening a scene 4 years down the line and not remembering which plugin I'm missing.

[Inisheer]

Do C++ nodes need to be installed? I love regular compounds because I don't have to install plugins or addons. As long as my scene has the compound with its factory nodes inside, it'll work hassle-free. I would hate opening a scene 4 years down the line and not remembering which plugin I'm missing.

Good point.

I think I'm probably a bit opposite from most ICE "developers" as I started programming long before working with ICE. So I think a bit better in code vs node.

However, I think you make a valid point and it sounds like we should use the built in tools whenever possible.

[Hirazi Blue]

Let me add my personal two cents to this C++ issue:
In principle I agree: creating projects purely in ICE would be preferable.
But if and when it can be seen as a necessary or at least highly desirable step to code a node in C++ I wouldn't shy away from it. If the person doing the actual coding offers a nice walk-through of the process creating it we could all learn a thing or two.
And in my experience deploying solutions in ICE might also ask for a bit of scripting to get things just right (and foolproof), again something we shouldn't shy away from. In the end the tools (to use in ICE and enhance Softimage) are the thing that matters IMHO, not the possibly somewhat hybrid way the were created.

[xsisupport]

If you have compiled nodes, then you'd package everything as an addon.

Like Lagoa, which has all compiled nodes and "regular" .xsicompound files packaged as an addon here:
C:\Program Files\Autodesk\Softimage 2012.SAP\Addons\Lagoa

For a community project, I'd assume you include the source.

[Inisheer]

If you have compiled nodes, then you'd package everything as an addon.

Like Lagoa, which has all compiled nodes and "regular" .xsicompound files packaged as an addon here:
C:\Program Files\Autodesk\Softimage 2012.SAP\Addons\Lagoa

For a community project, I'd assume you include the source.

Thanks for the info. I think the easy part will be coding. The hardest part so far is actually getting a custom node C++ project up and running on Visual Studio 2010.

Nothing but LNK2001 errors.

error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall XSI::ICENodeContext::~ICENodeContext(void)" (__imp_??1ICENodeContext@XSI@@UAE@XZ)

LNK1120: 89 unresolved externals

[Hirazi Blue]

@Inisheer - This seems to be a very specific topic you should address
(open a separate thread for) in our "Programming" forum to not derail
this specific thread unnecessarily IMHO...
;;)

[Inisheer]

@Inisheer - This seems to be a very specific topic you should address
(open a separate thread for) in our "Programming" forum to not derail
this specific thread unnecessarily IMHO...
;;)

Will do. Sorry about that.

[Tekano]

hi, so was thinking of trying to start a new community Ice project on animating and rendering clouds, its such a huge vague topic though and with no guarantees of completion or results...! , but is it ok to just start a new topic in Community ICE Project or is better to get general consensus here first or wait until the next one has finished or just start a new thread elsewhere like Ice Section > ICE ?

[Hirazi Blue]

I'd say: start a new thread now.
You can get a lot of work done before the community reaches a consensus
And if it doesn't work out, the thread simply dies, no harm done...