we had this same issue with making terrains for our games. We've tried various routes but the biggest roadblock is the lack of an open paint tool/system. The feedback loop is horrible, closed, and dog slow. We've lobbied for a paint system, but no fruit yet.
We've been wanting to use the new SDK UI toolkit to create our own brush system but I think what we overlooked is how the SDK tool kit is implemented - it lacks event hooks to trigger feeds and pushes when we'd like in order to provide the workflow experience that is expected. Then again, we're still on Softimage v7.5, so we can't use it anyway. We've tried the following techniques with various pros/cons: 1) Vertex color properties on mesh w realtime pixel shader. 2) ICE compound (testing only) reading weight property. 3) Compiled operator reading vertex color or userdata map. If you want a paint workflow, then #1 is the way to go. If you want an overall edit workflow, you'll be best served with #3. If you want the easiest to implement (eg: least experience required to get functional), go with #2. Each solution has it's problems. In the case of #1, the problem is your results are only viewable in the Realtime Shader > OpenGL viewport because the pixel/vertex shader will be doing all the work. That viewport is dog slow, but still faster than any of the other solutions and probably just fine if you use the object view instead of the general viewports to do the work. You will need some good knowledge of writing OpenGL shaders to get a worthwhile implementation. While you could use the shader editor and code it directly in softimage, the performance won't be quite as good and you'll hit a few bugs/limitations with the type of data you can read/write on the mesh. The ICE compound solution is probably the easiest to implement, but you'll run into massive performance issues as well as difficulty creating a property which can be easily modified to add/subtract deformers. It can be done, but a PITA having to do it in a node based system. This solution does not scale well. A compiled operator works really well as a generic solution and we have used it both with the vertex color property and the userdata map. The userdata map allows users to store as much data as they want and the programmer can store data as he sees fit. The downside is there isn't a lot of infrastructure in place to visualize the data in the userdata map. Hence the attempt at the vertex color property. The downside to the vertex color property is it only has 4 channels and it's data is more granular than what you need it for which raises the problem of how do you handle cases where a vertex has more than one color value? That solution incurs a small performance penalty. Another downside to this method is when the user works with referenced models and other dependency data. Compiled operators are not as graceful as ICE compounds when it comes to resolving missing inputs on scene load or similar issues. Upgrading the operator on legacy scenes can be tricky too. We mostly use #1 because artists preferred to use the paint brush than use any other editor to get/set data. Bottom line is Softimage needs a true paint system because the current implementation is horse shit and a blocking issue to serious games productions. Matt From: [email protected] [mailto:[email protected]] On Behalf Of Bradley Gabe Sent: Tuesday, April 17, 2012 11:04 AM To: [email protected] Subject: Re: Envelope Weights Without the Envelope Op? Could you be more specific in the type of control you want? Painting? Tweaking values in the weight editor? Using a property to store weights? Yes, all of these. :) I have an ICE operator that is assigning multiple states to particles based on weight map values. Rather than paint a separate weight map for each state, I'd prefer to be able to have a single map with multiple weight values. I could use bones and traditional envelope weighting, then mute the envelope and read the weight map in ICE and use the values to assign states. But as I said, that seems hacky, when I'd prefer not to go through an envelope operator. Vertex painting is not going to suffice because it's a royal PITA to work with compared to envelope weight painting. Matt From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Bradley Gabe Sent: Tuesday, April 17, 2012 8:11 AM To: [email protected]<mailto:[email protected]> Subject: Envelope Weights Without the Envelope Op? I'd like to be able to use the envelope weighting workflow to control a custom ICE deformer, rather than an envelope op. The hacky way to do this is to mute the envelope operator, but I was wondering if anyone has figured out a more direct way to get access to the weight painting workflow without applying the envelope deformation. -B
