Replies: 1 comment
-
I added Some design decisions (for now):
I watched a video on USD and decided it is too specialized (meant for large-scale production) and complicated for us at this point. Keeping things as simple as they can be is important. It's the top item on my kons-9 manifesto. Yes, I'm working on a manifesto. :) The video: https://www.youtube.com/watch?v=Yp_TRVD3wjQ I also decided to keep the transforms as is. I find it simple and flexible, and I've never liked Maya's node duality -- are you working on the node (transform) or shape (geometry). |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Greetings,
Starting new discussions on some design issues, the first one being our scene graph.
Currently we have the following classes for representing scenes:
scene
,group
,shape
, andtransform
Shape has a transform, and its subclasses such as
polygon
andpolyhedron
have geometry.The convention in most 3D systems seems to be to have the transform be a group node and contain one or more group or geometry nodes. I think USD files also have this setup. If so, maybe we should follow the same convention. I can't see a reason not to.
We also need to determine how to encode shape/geometry names (strings or symbols), and scene dag (hierarchy) paths.
In general, perhaps we should follow the example of the USD spec (which I have not read), so we avoid gratuitous conflicts down the road?
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions