Re: Idea- Just keep Mental Ray and FBX support - Softimage free w/Maya or Max or any Suite.
On 15/03/2014 17:44, Graham Bell wrote: I¹ve absolutely no doubt, but in all the time I¹ve demoed Softimage, even pre-AD, there was never anyone who didn¹t like the software, tech or couldn¹t see the potential benefits. However despite this, it wasn¹t easy for people to simply adopt. We could easily lead the horse to water, but never make it drink. Graham, as everyone at Autodesk seems convinced there is no market for Softimage what harm could there be in selling it? If the might of Autodesk's marketing resources had no impact then it stands to reason that no one else is going to be able to make a success of it. I mean you've tried your best, right? It's just not possible to market Softimage. Avid tried and failed, you tried and failed. It stands absolutely no chance of ever becoming a competitor to Maya or Max as it's too hard to adopt. Why not, therefore, sell it on to an interested third party who could solely cater for the niche Softimage audience? Don't we all win that way? We have an interested 'owner' - you can focus your resources on Maya and Max and walk away with a lump sum for 'innovative' R&D and you still have no competition. You no longer have an alienated and hostile Softimage customer base. Better still, as soon as Maya becomes a more attractive option we then have the choice to adopt or not. Given the myriad improvements listed by Chris that adoption in a few years time should be a no-brainer for us, shouldn't it? We can once more re-enter the Autodesk fold willingly and migrate to the better product. If you, Chris and Maurice genuinely believe in 'new' Maya and Autodesk's own marketing abilities it should be relatively easy to sell it to Softimage customers in a few years time. I'm sure we're going to be blown away by the new innovations that Maurice talked about. With the current roadmap and user input Maya will undoubtedly be a better product than Softimage is now. I know you wouldn't be asking us to transition to an inferior product - that just wouldn't make business sense. No billion dollar business would treat their customers that way. Fundamentally, it seems as though if the initial decision to buy XSI was motivated by a desire to move the product forward and market it in earnest (with a genuine business case that demonstrated either more sales or additional revenue - and why else would you have bought XSI?) then there has been a colossal failure in that business plan by Autodesk. The burden of that failure has been placed solely on the customers to whom, surely, Autodesk has some level of responsibility. And yet, that burden of responsibility doesn't seem to have been reflected in the manner in which Softimage is currently being EOL'd. I can't think of a more brutal scenario - immediate cessation of development; no prior warning; no safe-harbour alternative option; no pre-planning or understanding of the essential migratable features in Softimage; no in-place transition training; no concept of recompense for your failure; and no willingness to negotiate or ameliorate the terms of the EOL in any substantial way. Julian
Re: Custom ICE node port context types
On 23/07/2013 17:56, Vladimir Jankijevic wrote: Hi list, I'm having little trouble here with a custom ICE node. I didn't touch the subject for a long time so I'm a bit confused :) What I want basically is a node with an input which takes any context, loop over all the items from the input and output a single value. Is that even possible? I've found the BBoxGenerator example and that's basically what I want but I couldn't get my node to load in Softimage as soon as I have a different output Context type than what I have as input context type. Hi Vladimir, The only other things I can think of checking are maybe the context constraints when you define the ports i.e. make sure they're not using the same constraint map and, possibly, ensuring the node definition is set to single threaded (like BBoxGenerator). Using single threaded gives you much more latitude in mixing ports of different contexts whereas multithreading, by default, seems to enforce stricter rules about input/output port evaluation...often resulting in mixed input/output ports being evaluated incorrectly. In fact, almost all the time I find that multithreading requires that input and output ports be in the same context. I tend to use multiphase a lot of the time since it seems to bypass lots of port context issues (probably because all the initial phases are single threaded anyway). Julian
Re: Setting data on a particle based off data from another particle in the same cloud
On 17/07/2013 17:03, Grahame Fuller wrote: 3. Use Build Array from Set to put ParentID into an array. Find the parent's ParentID in the array. You should get an array with two indices, the one that isn't the parent is the cloned child (safe to say it will be the second one). That step is genius, gray. Works both ways - children to parent, parent to children - and couldn't be more direct, simple or unambiguous. Definitely one for the cookbook.
Re: Setting data on a particle based off data from another particle in the same cloud
Hi Alan, https://dl.dropboxusercontent.com/u/69741069/cross_querying.rar Not sure if this is what you're after but it establishes a relationship between the parent and the clone which enables the parent to later query the clone's attributes and set data on itself. It's quite hacky in that the only way I could quickly get a parent to know which particles it had cloned was via Get Closest Points on instantiation of the clones. In this scene the parent looks up the second strand position in the clone and shows you the resulting vector. I tried to figure out the ID allocation (making assumptions, for example, that the cloned particle would have the next ID along from its parent but that didn't seem to work) and it would be interesting to understand better how ICE allocates IDs to clones. On the other hand, I think it would be more elegant to do your stuff the other way round - it's always much easier to give a clone the id of its parent since it can directly inherit a custom attribute based on the original particles ID and then always find it again using ID to Location. So, in your case, maybe have the strand on the original particle and querying that from the cloned one (using the easier ID to Location stuff)? Julian
Re: Ice Spring Constraint
Not sure how helpful this is but it shows how to drive the kinematics of a 'Follower' null with a spring constraint acting on its ICE Kinematics. It requires a simulated tree. I don't think there's any way of producing the same effect without simulation. With only a modeling stack you only have access to the current frame's data. To use just press play and drag the 'Master' null around. You can play with damping, mass and stiffness. There's also an example of a projectile simulation (using the standard particle system and Simulate Particles) compared with a Null which has it's kinematics driven by a hand-built 'simulate' compound using a basic Euler integration technique (the same one, I think, they use in the built-in compound). All the concepts are directly transferable e.g. in this example both systems use the built in Gravity force and it works in the same way. Scene (2013 SP1) here: https://dl.dropboxusercontent.com/u/69741069/jj_spring_null_euler.rar Julian
Re: ICE: stick to surface without overlapping particles
On 13/06/2013 08:54, Steve Pratt wrote: Hi Julian, thankyou very much for the reply and the level of detail provided. Much appreciated. So if my instance is a sphere it should work shouldn't it? I will have another look at my ICE setup to see what I'm missing. Good to know that other shapes won't work, makes sense now that you've explained it. Hi Steve, Ah. I see what you're saying. Yes, if you're using sphere instances it should work fine but you need to then draw a distinction between your spacing size and particle size. Since your instances will probably have their size baked in e.g. a radius of 0.3 then the actual size you want them to be instanced at is 1 so that they're not scaled. In Dart Throw you'd use a spacing size of 0.3 and for your particle size use 1.0. If you're randomising your sizes in Dart Throw you just need to set the size of the particle to the ratio of output size to input size. I've put an example here showing instanced spheres and internal ICE 'Shape' Spheres where you should be able to see what I mean: https://dl.dropboxusercontent.com/u/69741069/dthrow_sample.rar Julian
Re: ICE: stick to surface without overlapping particles
On 13/06/2013 06:13, Steve Pratt wrote: Hi Guys, thanks for this great tool Julian, and thanks to Olivier for the sample scene that helped me get my head around it. As always, I had a play around and thought I had it completely sussed. Now a job has turned up and I can't quite get it to work with instances. Whenver I add instance geometry the instances interpenetrate. I've tried using the Instance Geometry node and plugging it into the Add Point node and tried the Instance shape node plugged into the Init Particle Data node, but with no success. Not sure what I'm doing wrong. Hi Steve, Dart Throw only works correctly with a spherical shape, sadly. It has no concept of the size of the instances on the particle it just assumes they're spheres governed by the particle size. I've been working on a couple of things recently in order to upgrade Dart Throw: the ability to input a specific array of sizes so that only those sizes would be used and a small script to add an ICE attribute to each instance group member specifying a correctly evaluated minimum sphere that would 'wrap' the instance geometry (which could be fed into Dart Throw's size array). Unfortunately, even a good minimum sphere (c.f. the very approximate min spheres in the SDK) can leave huge volumes of the sphere unoccupied (typically with a long thin instance) so the 'packing' can look pretty poor. With instances I'd recommend that you use a relaxation simulation technique and actual shape RBDs i.e. spread your instances loosely around the object you're trying to pack them onto and then apply forces to them to 'push' them onto the surface, each frame using the post sim region to stick the particle back to the closest location on the surface. With low elasticity and bounce, eventually, the instances will settle onto the surface and the native collision routines in the RBD simulation will take care of interpenetration. Once you're happy with the distribution freeze off the ICE tree. Julian
Re: ICE: stick to surface without overlapping particles
On 22/04/2013 10:40, David Saber wrote: Thanks Stephen, this seems very interesting. I partly managed to set up the thing by plugging a sphere in the Dart Throw node , then in "add point" then in the ice tree node. But the points do not have any shape, they're just black dots. I don't know what to do with the size output. On Julian's blog there's not manual and the example scene is outdated. Anyone knows where I could learn to use it? Thanks David David - to use the size output, plug the size array into the array port of a 'select in array' node. Get 'self.id' and plug that into the index port of the 'select in array' node. Set 'self.size' using the output of the select in array node.
Re: Place Highlight Tool
On 18/01/2013 09:58, Eugen Sares wrote: No, I was using beta 0.6. Hah, disance keeping works in 0.7. Very good! If you include regular objects for placement, too, you might want to consider renaming it to "PlaceReflectionTool" or something. Just a suggestion. Thanks again! Eugen - I know it's a pain continually updating but just to let you know v0.8b is available now and fixes the Nurbs Surface mesh bug
Re: Place Highlight Tool
On 18/01/2013 09:04, Eugen Sares wrote: Julian, since I'm putting the new tool to use at the moment: bug: does not work on Nurbs surfaces. Looking into the source, it should... feature request: - allow any object, not just lights. - keep distance of existing objects/lights. - place multiple selected objects/lights at once, for consistency's sake (makes only sense if the distances are kept). By then it would be even better than the 3ds max version... Hi Eugen, It's great that you're putting it to use and thanks for all your feedback. Your comments make total sense - I'll try and get some of that stuff done this weekend. The Nurbs surface problem is a regression. Like you say, it should work :-( BTW, are you using the very latest version v0.7b? This one now allows you to interactively alter the light distance (with the Shift key down) and does maintain the light distance if you pick up the same light again (the first time it interacts with the light it puts a parameter on it to store the light distance). However, the first time you grab a 'new' light it defaults to 4.0 units. I'll change that to maintain the distance to the 'hit' point even for new lights... Julian
Re: Place Highlight Tool
On 14/01/2013 10:52, Eugen Sares wrote: Thanks, Julian! This is getting nice... Mind sharing the source code again? Eugen, the source should be in the src directory of the Addon :-)
Re: Place Highlight Tool
Although it's not addressing all the feature requests so far, over the weekend I've updated the Addon to work on pre-existing lights which should provide support for Arnold and VRay. In the tests I've done with Arnold lights it works fine. i.e. just select an existing light or light root and the tool will take over manipulation of that light. Fixed a horrible bug (in my implementation) with non-uniform scaled normals. Source has been tidied and extensive use has been made of code kindly supplied in this invaluable thread: http://www.si-community.com/community/viewtopic.php?f=16&t=1658 Hopefully will get a chance soon to address moving the light along the incident ray in a useful way. For the moment all lights are place a fixed distance away. Suggestions for what to do with the mouse vectors and how to derive a sane, non-flickering, predictable in/out motion for the light when Shift LMB pushed gratefully received! New addon is here: http://julianjohnsonsblog.blogspot.co.uk/2013/01/place-specular-highlights.html Julian
Re: Place Highlight Tool
On 10/01/2013 09:54, Stefan Kubicek wrote: Awesome! Just get ready for the inevitable flood of feature requests! ;-) Here's one: When no light is selected, create a new one. When a light is selected, use that to place the highlight instead of creating a new one. For inspiration: I stumbled over the HDR Light Studio website after following some links from yesterdays thread about PiVR. Here's a video demonstrating the workflow: http://www.hdrlightstudio.com/video.php?vid=49753201 That looks really slick. It creates an HDR image instead of lights, but the workflow looks really refined. I love the fact that you can create area lights too and adjust their shape. Stefan - agreed on the idea of creating a light with none selected and modifying and existing light if one is. Loved the video. Julian
Re: Place Highlight Tool
On 10/01/2013 09:42, Brent McPherson wrote: Julian, If I had to approach this in the tool SDK I would probably just store the relative mouse offset that was applied while shift-dragging and add this onto the input mouse position when not shift-dragging. That way the spotlight position wouldn't jump or change when using shift-dragging. (because the offset would cancel out the effect of shift-dragging) You should also consider sharing the source code so others can help you improve the tool. Thanks Brent, that sounds good. I guess it would mean that once the user had done some Shift+LMB dragging the mouse cursor itself would no longer sit on the specular highlight but the OGL target point would? Source is woefully ropey and unstructured at the moment: https://dl.dropbox.com/u/69741069/jj_SpecularPlaceTool.0.5.source.rar Lots of structural questions like whether for performance reasons it would be better to remove the GetGeometry() queries from MouseDrag and only renew/cache geometry when the object under the cursor has changed and, at the same time, setup Closest Location Queries with the relevant transforms on that change. Was getting a huge number of PointLocator errors with my initial attemptsso it all remains dumped in the MouseDrag function. I'm sure there are much, much better ways of doing it. Julian
Re: Place Highlight Tool
On 09/01/2013 21:00, Brent McPherson wrote: Just curious. Did you keep the shift modifier key from the original tool as a way to adjust the distance of the light from the surface? (Don't have a build I can use to install the tool right now...) -- Brent Hi Brent, I intended all along to do that but I couldn't figure out how to resolve the fact that if you adjusted the mouse position with the Shift key down (adjusting the distance the light travelled from the intersection point) and then released the Shift key the specular highlight would then snap to the new mouse position. Ideally, it would be nice if the scroll wheel on the mouse could be used to control the light 'height'... Julian
Re: Place Highlight Tool
On 09/01/2013 20:15, Eugen Sares wrote: Ok, tested it. What you do is create a new light every time the tool is called. May I suggest something? It would be better if you allowed selected lights to be moved instead of creating new ones, keeping the distance between the light and the surface. This way, you could also ignore the light type (spot, omni, directional, VRay, Arnold, whatever). Light is light... Would that be possible? For convenience, you could also attach the command to the "Transform" menu. Hi Eugen, Thanks for the great feedback! As you say, it's relatively straightforward to swap out the light shader for a third party one. In Arnold's case some of the light rigs require a bit more hand tweaking e.g. they automatically come with expressions set on area scale etc. Would be good to either have a preference setting or context menu to select the light type you want to add and then build those presets into the tool so that they're available. The core code is based on the SDK SpotLightCreateTool which behaves exactly in the way you're seeing. Moving existing lights is a priority and coming next :-) but it might have to wait for another holiday period! Thanks again, Julian
Re: Place Highlight Tool
On 04/12/2012 10:23, Brent McPherson wrote: Hi Eugen, Yes, it would be simple to do with the Tool SDK. In fact, we already have a spot light creation tool example that ships with Softimage (search for SpotLightCreateTool in the custom tools addon) so only the reflected ray part would need to be added. Anyone up for the challenge? ;-) Belatedly picking up the gauntlet and thread. Had some time to fiddle around with the Tool SDK over the Christmas holidays and cannibalised the SpotLightCreateTool as Brent suggested. Tool SDK has been great to work with. I'm in renewed awe of Piotrek Marczak's work (Meshpaint, Soft Transform) using the SDK. First usable stab linked below (addon and movie). http://julianjohnsonsblog.blogspot.co.uk/2013/01/place-specular-highlights.html Julian
Re: Place Highlight Tool
On 04/12/2012 09:16, Eugen Sares wrote: Hi, I'd have good use for a tool to place highlights/reflections. Select a light (or any other scene object), click/move cursor over any surface, and the light gets placed on the reflected ray of the camera -> surface point ray. 3ds max has such a tool since forever. For Softimage, I could only find an old script by Guy Rabiller. Did I miss something? Should be possible to implement this nicely with the Tools SDK, I guess. Anyone? Hi Eugen, This is not what you want! :-) But I built a rough tool to accurately see what I'd get reflected for a recent advert we did. I've been meaning to work it up into a proper 'applyable' utility that lets you pick the relevant target and reflection groups (and to constrain the target null to the camera plane etc). Just can't find the time at the moment and it's just sitting there. Anyhow, I quickly added a tree to a light to pull the data out of the reflection ray and allow you to also position a light on the ray. The scene file (2013) is here: http://www.exch.demon.co.uk//xsi/files/reflectionray.rar Your suggestion is much nicer obviously and it would be great if one of the tool SDK experts had a crack at it! In the meantime, at least this gives some kind of quarter way house...although I haven't checked out Guy's tool so it might still be totally useless. Julian
Re: Softimage Creatives London - next event Nov 13th
Just wanted to congratulate all the organisers and presenters at the Event. It was a really good evening. Fabric's presentation helped clarify a lot of issues; Anna's gave a great insight into the creative workflow involved in making a short; and I liked The Mill's presentation - particularly the insight that the Flame Ops discarded most of their passes in favour of the beauty. Genius. Following on from the nVidia presentation, we stayed up late last night and installed racks of pervy GPUs into our farm (I'm sure that's what he said!) and now we're all working from home. Cool. Congratulations and thanks to everyone involved. Julian
Re: Merge Topo Array - getting the index
@ Ciaran, That's very nice! Yes, my ICE Attributes are just scripted in @ Vincent I had just been looking at your earlier example this lunchtime: https://groups.google.com/forum/#!msg/xsi_list/utMwDX74NSY/mbaghEem8VAJ for summing vector lengths to see if it was usable here. It obviously was. Great stuff.
Re: Merge Topo Array - getting the index
On 02/10/2012 23:38, Peter Agg wrote: Hey list, I'm trying to use ICE Modelling to combine a number of meshes so I can write a single deformer which acts on them all. I've got a group with all the meshes in so I can just plug that into the Merge Topo Array just fine. However I need to record the index of the object the verticies were created from so I can use it as an ID in the Random Value node. Anyone know of any way to doing this at the moment? Keep thinking there must be a better way but here's a first go (if I understand correctly what you're doing): http://www.exch.demon.co.uk/xsi/files/merge_topo.rar (Some funky stuff when trying to use the Mesh_IDs and Switching Context in the tree on the deformed object so had to use a workaround). Julian
Re: 2013 SP1 Compile Error in VS2010 SP1
On 13/09/2012 11:40, Chris Chia wrote: Troubleshoot: Try to create a custom plugin (VS2010) of your own and see whether it could be compiled... Hi Chris, It seems like just tweaking the .bat file solves the problem. I originally had the call to vcvarsall.bat in, but when I commented it out: @echo off call "C:\Program Files\Autodesk\Softimage 2013 SP1\Application\bin\Setenv.bat" rem call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" amd64 rem set PATH set XSISDK_ROOT = "C:\Program Files\Autodesk\Softimage 2013 SP1\XSISDK\" "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" echo on Everything seem to work fine! Cheers, Juian
Re: 2013 SP1 Compile Error in VS2010 SP1
On 12/09/2012 18:48, Alok wrote: We had this in VS2010 for 2012 but I am not sure about 2013. Basically what we did was to use our own MACROS or variable instead of the one from setenv.bat. All you need to do is take your project generated from the wizard , start visual studio normally with call to setenv.bat and make your own solution and in the properties set the paths for include and libs for XSI manually. That should not work. At least it did for us. Thanks Alok. Will try that...
2013 SP1 Compile Error in VS2010 SP1
Just moving from VS2008 to VS2010 SP1 for 2013 SP1 and getting this compile error when trying to build any of the custom tools or ICE nodes (e.g. SnapTestTool/CustomPassThrough): 1>TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\CL.exe" @C:\Users\Julian\AppData\Local\Temp\aa1a941ecf4d479fafe00df2f75cc872.rsp". The handle is invalid. Has anyone seen this or have a solution? Tried the workarounds here: http://connect.microsoft.com/VisualStudio/feedback/details/505682/x64-c-c-projects-cannot-compile But didn't seem to help. Julian
Re: Crowd FX Help
On 01/08/2012 18:09, Steven Caron wrote: i dont recall this bug being addressed in 2013 SP1, but i may be wrong... @julian, i got to the point where i was adding all the characters i needed to an empty scene and updating this, then copy pasting graphs to rebuild the scene. but even in a simple scene eventually screeches to a halt. being able to use a external format to store data like this and so it can be updated without interacting with a live simulation is key. Thanks Steven, I think I'd need to do the same as you. Did you find you had problems simply adding new Actors to an established crowd? I not only get the ultra long load times but it quite often ends with: # ERROR : CrowdSkinningNode: 428$Access to a custom ICE node input port failed. Again, this only happens if I reload an existing crowd scene. The same model adds fine provided I don't close and reload the scene. It also works properly in a neutral scene on it's own... Cheers, Julian
Re: Crowd FX Help
On 01/08/2012 15:12, Guillaume Laforge wrote: Hello Julian, It sounds like a known bug reported by Steven Caron about extreme slowdown when adding new actor sources. It was fixed in 2013SP1 (several optimization in the scene graph validation and topology update were done). Hi Guillaume, Thanks for the quick response. Yes, we're on SP1 (build 11.1.57)...and the slowdown is quite dramatic. Cheers, Julian
Crowd FX Help
I'm struggling with extreme slowdowns and erratic actions in CrowdFX. Specifically, when I reload a scene and then try and add new actor sources a) the new actor source takes ages to load and b) often the new source's animations are somehow corrupted with either a weird animation cycle, stuttering or a permanent static pose. These same cycles work fine in solo scenes. If I recreate the scene from scratch everything works fine but as soon as I quit and reload it seems like from that point onwards I can't really add/remove actors or change actions without some of the behaviours above. I think it seems worse with actors that have been unloaded and reloaded (using Get From Scene). The only solution I can think of is to script the building of the whole scene from scratch each time. Has anyone else experienced this or found any workarounds? Julian
