Re: What were they thinking....
Hum. Just noticed I double posted, and had an incomplete first phrase... what was I thinking! :P On 08/28/17 12:27, Jason S wrote: Hum, didn't know that these differences. Also maybe another quite important way Maya probably wont come close to XSI could be represented by that highlighted arrow . From this vid at around 9min. Pipeline Basics In Maya, once something is rigged (for instance), even changing UV's (or materials?) is like 'dangerous' or risky. Having the character refrerenced seems to at least help with *some* model changes. While In XSI, you can literally make tweaks to modeling while the envelope is active, add (topo) details, or change whatever on the fly, freeze the changes or not, no worries. Because that highlighted arrow quite often needs to be repeated over and over a couple of times. and it's a great level of freedom, to just go and change things, and not have it be the end of the world in terms of time requirements. That of course goes for rigging, but it also goes for practically every kind of setup, or sequence of operations to perform. like Subdividing ... shrinkwrapping... the list goes on ... To change things you don't -have- to redo things, or need to have scripts that redo things. The stack has it's share of wonkyness, I personally have had to have a couple of muted Push operators just as placeholders that help position things at the very top or very bottom of the stack, and it took forever to realize how "disable from here" helped reorder or insert otherwise unreorderable things, but once over these few things, there is no stage that has things that become inaccessible, inedtable, or non-deletable, and that includes ICE operators. That of course doesn't in any way reduce Maya's definite strengths in different areas. Maybe in the best of worlds, Maya and Houdini would be merged into one thing (and owned by sideFX), but thinking of a Maya/Houdini merger, it's hard to not think about XSI, because that is what it essentially is (except with also tons of c4d straight forwardness, because a straight Maya/Houdini hybrid would be as much of a pain to use as either one of them on their own :P ) Anyhoo, Cheers! On 08/25/17 16:36, Matt Lind wrote: The Maya SDK is no better. Excruciating teeth-pulling experience to do really basic things as concepts are not explained, or explained well. Every node is purpose-built and has it's own secret handshakes to use making it difficult to write generalized and reusable code to perform common tasks. Using the SDK basically involves studying the graph as seen in the node editor, dissecting how it was built, then repeating it in your code...only to find out even if you replicate the exact same setup it doesn't behave the same. There are additional hidden tricks you must know to get those last pieces to drop into place. You can very easily fall into the trap of attempting to write your own abstraction layer just to make the pieces less cumbersome to use, but just when you think you've wrapped everything nicely, Maya throws you one of it's endless supply of idiosyncratic surprises. Example: constraints In softimage, each constraint is a separate operator that lives in an object's construction history. Every time you add a constraint, it is added to the construction history in the order which it was applied. A lot more may be going on under the hood, but to the end user it's very straight forward. In Maya, if you attempt to add more than one of the same type of constraint to an object (e.g. two point constraints), instead of making two distinct constraint operator nodes like in Softimage, Maya consolidates them into a single constraint node with multiple inputs blended internally - but you have to supply your own blendweight slider to do that (they don't mention that in the SDK docs). Since each constraint type has slightly different inputs and outputs, you write your own abstraction layer to handle the differences, only to discover that if two different types of constraints affecting the same attribute of an object are applied (e.g. point and parent constraint competing for the 'position' attribute), Maya throws the curve ball of inserting a 'pairBlend' node, which is like mix2colors node, but for transforms instead of colors. Great. Now you must revise your logic in your
Animated booleans now and then
Hi list, I had several projects lately that involved animated booleans with CAD data, which is problematic sometimes. I used the old BoolTrace shader by Alan Jones but it has its drawbacks: With many objects, using different materials, it's hard to keep track of the shaders. Another problem was, that there is a limitation in the shader with reflections. Let's say you have a box and a sphere and the box is cutting the sphere in half. If another objects that is reflective, intersects the cutting volume (the box) it will reflect the box by it's primary rays. I assume that is because the shader interchanges primary and secondary rays under the hood. I could potentially get it solved by using passes/partition trickery or another shader to get selective reflections on object basis. However, this becomes quite complicated with a handful ob objects, all using different materials. On some projects I switched back to real (geo) booleans and fixed the "popping" of meshes by slighty adjusting the fcurves or cleaning the topology a bit, but its a hack. On another project I got away with slightly incorrect reflections using render time booleans. At the end it worked somehow but it was almost never elegant or straight forward. Is there an alternative to the (rather old) booltrace shader for XSI? Anything for redshift in that area? Last, not least, how do you approach animated booleans with complicated/heavy meshes nowadays? Thanks, Sven -- Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Re: What were they thinking....
Hum, didn't know that these differences. Also maybe another quite important way Maya probably wont come close to XSI could be represented by that highlighted arrow . From this vid at around 9min. Pipeline Basics In Maya, once something is rigged (for instance), even changing UV's (or materials?) is like 'dangerous' or risky. Having the character refrerenced seems to at least help with *some* model changes. While In XSI, you can literally make tweaks to modeling while the envelope is active, add (topo) details, or change whatever on the fly, freeze the changes or not, no worries. Because that highlighted arrow quite often needs to be repeated over and over a couple of times. and it's a great level of freedom, to just go and change things, and not have it be the end of the world in terms of time requirements. That of course goes for rigging, but it also goes for practically every kind of setup, or sequence of operations to perform. like Subdividing ... shrinkwrapping... the list goes on ... To change things you don't -have- to redo things, or need to have scripts that redo things. The stack has it's share of wonkyness, I personally have had to have a couple of muted Push operators just as placeholders that help position things at the very top or very bottom of the stack, and it took forever to realize how "disable from here" helped reorder or insert otherwise unreorderable things, but once over these few things, there is no stage that has things that become inaccessible, inedtable, or non-deletable, and that includes ICE operators. That of course doesn't in any way reduce Maya's definite strengths in different areas. Maybe in the best of worlds, Maya and Houdini would be merged into one thing (and owned by sideFX), but thinking of a Maya/Houdini merger, it's hard to not think about XSI, because that is what it essentially is (except with also tons of c4d straight forwardness, because a straight Maya/Houdini hybrid would be as much of a pain to use as either one of them on their own :P ) Anyhoo, Cheers! On 08/25/17 16:36, Matt Lind wrote: The Maya SDK is no better. Excruciating teeth-pulling experience to do really basic things as concepts are not explained, or explained well. Every node is purpose-built and has it's own secret handshakes to use making it difficult to write generalized and reusable code to perform common tasks. Using the SDK basically involves studying the graph as seen in the node editor, dissecting how it was built, then repeating it in your code...only to find out even if you replicate the exact same setup it doesn't behave the same. There are additional hidden tricks you must know to get those last pieces to drop into place. You can very easily fall into the trap of attempting to write your own abstraction layer just to make the pieces less cumbersome to use, but just when you think you've wrapped everything nicely, Maya throws you one of it's endless supply of idiosyncratic surprises. Example: constraints In softimage, each constraint is a separate operator that lives in an object's construction history. Every time you add a constraint, it is added to the construction history in the order which it was applied. A lot more may be going on under the hood, but to the end user it's very straight forward. In Maya, if you attempt to add more than one of the same type of constraint to an object (e.g. two point constraints), instead of making two distinct constraint operator nodes like in Softimage, Maya consolidates them into a single constraint node with multiple inputs blended internally - but you have to supply your own blendweight slider to do that (they don't mention that in the SDK docs). Since each constraint type has slightly different inputs and outputs, you write your own abstraction layer to handle the differences, only to discover that if two different types of constraints affecting the same attribute of an object are applied (e.g. point and parent constraint competing for the 'position' attribute), Maya throws the curve ball of inserting a 'pairBlend' node, which is like mix2colors node, but for transforms instead of colors. Great. Now you must revise your logic in your abstraction layer to account for that. Then you start testing again applying a point constraint, then a parent constraint, then another type of constraint which also competes for the position attributeonly to discover Maya now removes the pairBlend node and rearranges the constraints into an entirely different arrangement
Re: What were they thinking....
Interesting, didnt knwo that about constraints! Also maybe another quite important way Maya probably wont come close to XSI could be represented by that highlighted arrow . From this vid at around 9min. Pipeline Basics In Maya, once something is rigged (for instance), even changing UV's (or materials?) is like 'dangerous' or risky. Having the character refrerenced seems to at least help with *some* model changes. While In XSI, you can litterally make tweaks to modeling while the envolope is active, add (topo) details, or change whatever on the fly, freeze the changes or not, no worries. Because that highlighted arrow quite often needs to be repeated over and over a couple of times. and it's a great level of freedom, to just go and change things, and not have it be the end of the world in terms of time requirements. That of course goes for rigging, but it also goes for practically every kind of setup, or sequence of operations to perform. To change things you don't -have- to redo things, or need to have scripts that redo things. The stack has it's share of wonkyness, I personally have had to have a couple of muted Push operators just as placeholders that help position things at the very top or very bottom of the stack, and it took forever to realise how "disable from here" helped reorder or insert otherwise unreorderable things, but once over these few things, there is no stage that has things that become inaccessible, inedtable, or non-deletable, and that includes ICE operators. That of course doesn't in any way reduce Maya's definite strenghts in different areas. Maybe in the best of worlds, Maya and Houdini would be merged into one thing (and owned by sideFX), but thinking of a Maya/Houdini merger, it's hard to not think about XSI, because that is what it essentially is (except with also tons of c4d straight forwardness, because a straight Maya/Houdini hybrid would be as much of a pain to use as either one of them on their own :P ) Cheers! On 08/25/17 16:36, Matt Lind wrote: The Maya SDK is no better. Excruciating teeth-pulling experience to do really basic things as concepts are not explained, or explained well. Every node is purpose-built and has it's own secret handshakes to use making it difficult to write generalized and reusable code to perform common tasks. Using the SDK basically involves studying the graph as seen in the node editor, dissecting how it was built, then repeating it in your code...only to find out even if you replicate the exact same setup it doesn't behave the same. There are additional hidden tricks you must know to get those last pieces to drop into place. You can very easily fall into the trap of attempting to write your own abstraction layer just to make the pieces less cumbersome to use, but just when you think you've wrapped everything nicely, Maya throws you one of it's endless supply of idiosyncratic surprises. Example: constraints In softimage, each constraint is a separate operator that lives in an object's construction history. Every time you add a constraint, it is added to the construction history in the order which it was applied. A lot more may be going on under the hood, but to the end user it's very straight forward. In Maya, if you attempt to add more than one of the same type of constraint to an object (e.g. two point constraints), instead of making two distinct constraint operator nodes like in Softimage, Maya consolidates them into a single constraint node with multiple inputs blended internally - but you have to supply your own blendweight slider to do that (they don't mention that in the SDK docs). Since each constraint type has slightly different inputs and outputs, you write your own abstraction layer to handle the differences, only to discover that if two different types of constraints affecting the same attribute of an object are applied (e.g. point and parent constraint competing for the 'position' attribute), Maya throws the curve ball of inserting a 'pairBlend' node, which is like mix2colors node, but for transforms instead of colors. Great. Now you must revise your logic in your abstraction layer to account for that. Then you start testing again applying a point constraint, then a parent constraint, then another type of constraint which also competes for the position attributeonly to discover Maya now removes the pairBlend node and rearranges the constraints into an entirely different arrangement you cannot predict. This is why Maya will always suck. Probably also explains
