RE: [Algorithms] Future of graphics question (maybe OT)

[Killpack, C. <Ch...@ea...>]

A graphics package such as Houdini is much more suited to this kind of
content authoring. Houdini works in a very procedural way - you have a
series of SOPS (Stream Operators) & CHOPS (Channel Operators - usually for
MoCap, skeletal data) that do different things which you wire together
connecting the output of one into the input of another. You can then editor
the behaviour/paramators of each *OPS. It's a very powerful system but it's
takes a while for artists to get used to.

> That's exactly what would be nice to see, though. The full 
> power, without
> the asm revealed. We've gone the normal way: we have VU code 
> that we do, and
> when we need to play with the register setting packets, we do 
> that too,
> leaving a (limited) palette of options for the artists to 
> choose from. It
> works, but it's not ideal.

Well perhaps. I am arguing that if you give people access to all the power
then they can get overwhelmed by it all. I suppose however this is more a
question of interface design - how do you present the data to the user? How
does a user interact with that data? It's a tough challenge though: how do
you shield the more complex systems away from new users while still keeping
them available to complex users? Bury those complex features 6 menu options
down? Hmm... I'm not so sure. A common complaint of 3DS MAX (which I hear
from MAX-hating zealots) is that it takes several mouse clicks to perform
some operations. But I digress.... and I'll shut up now. :)

Chris

> -----Original Message-----
> From: Jamie Fowlston [mailto:jfo...@re...]
> Sent: Thursday, May 31, 2001 2:13 AM
> To: 'gda...@li...'
> Subject: RE: [Algorithms] Future of graphics question (maybe OT)
> 
> 
> I don't think Maya cuts it. I've not seen anything that does. 
> I'm not even
> sure how it could work, at the moment. I'm sure it will seem 
> obvious once
> it's been done :)
> 
> [Snip]
> I think people will add UI's for the user which feed results into
> your plug-in which returns data back to the program for rendering
> [/Snip]
> 
> A lot of people are doing this already. That sort of plug-in 
> could be a
> first step, but ultimately it all needs to be better 
> integrated into how we
> work, I think. It also relies a great deal on the 
> representations we choose
> allowing the artists to do what they want (or some suitable 
> compromise being
> found).
> 
> [Snip]
> I admit that this system doesn't realise the full power of 
> vertex and pixel
> shaders but I think a tool that reveals all features will be counter
> productive - the UI would be messy, the system would be too 
> confusing and
> people would get sidetracked into extraneous details. Such an 
> example of
> this is providing them with an assembler and a text editor. :)
> [/Snip]
> 
> That's exactly what would be nice to see, though. The full 
> power, without
> the asm revealed. We've gone the normal way: we have VU code 
> that we do, and
> when we need to play with the register setting packets, we do 
> that too,
> leaving a (limited) palette of options for the artists to 
> choose from. It
> works, but it's not ideal.
> 
> Jamie
> 
>