...and how do you propose we get the ICE data into the engine while fitting into existing game play AND not introducing bugs AND not introducing more work for the engineering staff AND not requiring file format changes which would force us to re-export all assets which precede it - we have nearly 9 year of backlog which would need to be supported?
In film/video terms, imagine introducing your next tool required you re-submit every shot back to the render farm to be re-rendered and forwarded to every department afterwards to redo their work (compositing, fx, color correct, audio, editing, conforming, etc...) - when 90% of the work is in the can and people are already working 16 hours days 7 days a week. Probably wouldn't be a popular decision. When resources are scarce, solutions issued to artists of limited knowledge/skill must be in a form they can manage unsupervised which are also safe from jeopardizing the production. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Alan Fregtman Sent: Tuesday, February 11, 2014 12:33 PM To: XSI Mailing List Subject: Re: Survey - how would you do this? It's too bad about the No ICE rule because it's not terribly hard to write a pointcloud exporter to whatever format the engine takes. On Tue, Feb 11, 2014 at 2:23 PM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was 'good enough'. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow - like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: - Cannot use ICE - Cannot use custom scripts, custom operators, or shaders. - Must only use tools out of the box that a junior or staff level artist would know how to use. - Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes - and be iteration friendly to react to art director feedback. - Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet's size/shape/tilt/orbit. - Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. - Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready.....GO! Matt
