Thanks, Jody, for clarifying your ideas, it all makes more sense to me now. Well, I'll go ahead and do some proof-of-concept hacking. I'll come back as soon as there are any results or further questions...
Harald > -----Ursprüngliche Nachricht----- > Von: [email protected] > [mailto:[email protected]] Im Auftrag > von Jody Garnett > Gesendet: Dienstag, 17. März 2009 02:06 > An: User-friendly Desktop Internet GIS > Betreff: [udig-devel] RenderContext for scenegraph is a good idea > > Further clarification - I may of got the class names wrong. I > recall RenderExecutor, RenderCreator and RenderManager. > > > I don't really see why you said there is no need to extend > Renderer(Impl)... It's the RenderManager that creates > Renderers (via RenderCreator), and I need a Renderer knowing > how to create a javax.j3d.Shape3D from an org.opengis.Feature. > > > > What you seem to have in mind in plugging into the very end > of the 2D rendering pipeline by providing a specialized > Graphics2D which creates 3D objects instead. That might work > in principle, but I would lose information, as there is no > way to tell which 2D draw primitives come from the same feature. > > There are two stages to rendering; matching Layers with > Renderers - I do not think we need to change this decision > making process at all (we may have to implement additional > renderers; and we may have to add some more information to > the RenderMetrics - but the idea of defining the layers > seperate from the code that does the work of visualizing them > is sound). > > Where I got you confused was in the technical tradeoffs with > making use of the GeoTools StreamingRenderer. I agree you > will need to make a uDig Renderer for drawing features into > your scene graph. > > Then I got excited and talked about different ways you could > reuse the GeoTools streaming Renderer (and thus make use of > the style layer descriptor data structure etc...). Sorry for > the distraction. > > In terms of the render( graphics2d ) method - we are going to > hit that from printing; if your renderer does not support > this then we better make sure the RenderingMetrics indicates > that it is not a suitable choice when we go to print. > > For the render( progressmonitor) method - this is the one you > want. I know the implementations you look at now focus on > grabbing a raster out of the RenderContext(). > > Your implementations are not going to do that - they may > choose to store a scene graph data structure on the graphics > context? Then your rendering code can add to that scene > graph? The actual specific way you want to do this is up to you. > > Jody > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel > ******************************************* innovative systems GmbH Navigation-Multimedia Geschaeftsfuehrung: Edwin Summers - Kevin Brown Sitz der Gesellschaft: Hamburg - Registergericht: Hamburg HRB 59980 ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. ******************************************* _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
