RE: XSI Suggestion / feature request- more on the ultimate relation editor that I have

["Simon Pickard" <mail(at)simonpickard.co.uk>]

Hi Luke,

 

I had this exact same idea a while back; I posted about it on xsibase but can’t find the thread anymore L

 

I agree that having one central node based view would be great. We currently have 3 views (render tree, fx tree, and schematic) that all kind of work in the same way. If you add a node based particle view to this as well, which by the sounds of all the feedback we’ll get one day, the idea of making these views standard looks very interesting.

 

I also started to think about how these currently separate areas of xsi could start to work together as you have. It suddenly opens up all kinds of possibilities if you think in terms of being able to add fxtree nodes into a rendertree, etc, etc.

 

I guess the main problem would be getting all these data types to “talk” to each other. Not an easy task I’m sure. But personally I’d love to just see a central node view even if all these linked pathways weren’t open to start with. Just having a single view where everything works the same, has the same hotkeys and workflow, etc, has my vote.

 

Regards,

Simon.

 

 

 

---

From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of lpiasecki76
Sent: Sunday, October 02, 2005 3:32 AM
To: XSI(at)Softimage.COM
Subject: XSI Suggestion / feature request- more on the ultimate relation editor that I have

 

My apologies for all the emails I have sent this weekend.

I don’t mean to spam you, I just had a bit of extra time to work with XSI 5.0 and a few ideas surfaced.

I have mentioned this editor in one of my previous emails and I thought I could elaborate a little bit more here. Although I have only seen Houdini a few times in the past, I understand that the idea is very similar to the paradigm that Houdini uses. This by no means would be an easy thing to implement and would most likely take a few releases as well as a lot of user feedback, experimenting and usability tests.

What I would like to propose is a centralized schematic/node-based/relationship editor for any node based relations in the software. This editor would replace or enhance ideas of Render Tree, Behaviour, Deformations, Particles, Schematic view and perhaps even compositor. Its main purpose would be to integrate everything in the software. It seems that it fits very well with the ‘upcoming’ particle system, outdated schematic view, requests for deformation blending, lack of current integration in the dynamic system, improvements to expressions and SCOPS.

Some main ideas:

-          The editor would be comprised of all kind of nodes and defined events/triggers/relations between them.

-          All the nodes are open; you can plug anything into anything as long as the inputs/outputs match.

-          It serves as a visual _expression_ editor, so conditions, iterations are allowed.

-          Many utility nodes would be provided, e.g. get point vector, distance to, collides with, enters volume, closest point on curve/surface etc.

-          It allows for collapsing of the nodes.

-          All functions from Behaviour become nodes, a state machine is also provided (replaces Behaviour)

-          Allows for integration of all solvers, e.g. you can get collision data from two rigid bodies colliding and feed that into render tree or anything you can imagine. Particles can push rigid bodies and deform soft bodies etc.

-          User can define events, triggers, zones, etc. which will trigger animations or behaviours.

-          Parallel deformations, blending between them etc. can very easily be visualized.

-          Rendering nodes can be linked into other nodes, such as for instance the velocity of the object can be linked to a colour of its texture or vice versa.

-          Advanced behaviours such as ‘transfer attributes from overlapping objects’ are also provided, when particle enter a volumetric objects which has some attributes defined, their attributes will start to change (depending on falloff etc.) this would be an extension of triggers. An object which overlaps another object could automatically transfer textures from the other object upon overlap.

-          Split history – while modeling in construction mode the user can split history at any time, allowing for different version of the object and merging the chains later on in the chain.

-          Any SCOP can become a node, which can then be plugged to other nodes/SCOPS.

-          Nodes can have multiple inputs and outputs.

-          Multiple materials and render tree nodes of different objects can talk to each other.

-          One can quickly drag and drop parameters from those nodes to create custom GUIs so a user does not have to go through the nodes to edit what they need the most.

-          Visualization – an idea beyond shader balls – the little nodes show thumbnails of objects, materials, particle animation as it changes from node to node. Nodes can be quickly muted or reordered.

-          Of course this editor would also provide nodes for a particle system, however I will not go into details here since so any great suggestions have been posted at XSIBase.com

 

 

I understand that designing such system would be a huge challenge, but if properly implemented this could be a great addition to the package.

 

Let me know what you guys think.

 

Luke