Re: [Repast-developer] Splitting DisplaySurface3D

[Thomas R. H. <th...@sr...>]

This seems good to me.  Keep all of the rendering stuff (simpleUniverse,
etc) in the "Display" class.  Then you can still have a DisplaySurface
that is the Frame, event handler, and deals with all of the probing. 
Basically this will look very similar to what we talked about yesterday,
except that the SimpleUniverse will reside in the display instead of the
displaySurface.  This would allow the user to add multiple displays to
one displaySurface if, God forbid, they wanted to.  This sounds very
good to me.  I need to think about what DisplaySurface3D would need to
look like.  But I bet it looks a lot like DisplaySurface.  Maybe I can
refactor DisplaySurface so that it would work with 3D spaces as well.

-Tom


On Mon, 2002-12-30 at 13:39, Phil Feldman wrote:
> Tom,
> 
> I've been looking through my DisplaySurface3D code and I'm thinking that 
> the canvas3D/SimpleUniverse split will make things uglier. The reason is 
> that PickUtilities requires both the canvas3D and the root of the scene 
> graph in which the picking will take place. That means that the display 
> and surface classes would have to have enough knowledge of each other 
> that splitting them doesn't' make sense to me. Additionally, 
> SimpleUniverse actually supports only *one* Canvase3D, even thought 
> there is a getCanvas that can retrieve by index.
> 
> Rather than that, what might work easier is to have the particular scene 
> graph generated or imported by the user load into a
> UserSceneGraph class that would correspond (somewhat) to Display. You 
> could have classes for CustomSceneGraph, XMLSceneGraph, etc that would 
> handle the particulars of the scene graph setup and feed them to the 
> DisplaySurface3D.
> 
> Thoughts?
> 
> Phil
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Tom Howe
Social Science Research Computing
University of Chicago