JReality talk
 

Table of contents

Lights as shaders

Taking up this theme again, after a long hiatus. Provocation is the recent addition of methods on Light to identify "fake ambient" lights which shouldn't be written out for fancier ray-tracing backends. This raised the question whether such properties shouldn't be handled as attributes in the Appearance attached to the Light. Here's a proposal to shift the bulk of the light information into such attributes, while still leaving the light field in the SceneGraphComponent:
Gunn 12:47, 7 Dec 2006 (CET)

Viewer VR feedback

Just a few random responses to the current state of the ViewerVR app (on the web site):
Gunn 16:55, 20 Nov 2006 (CET)

software viewer update

Since I was not at the last jReality-meeting, I want to report on the status of the software viewer here. For two month or so, I have develpoed and tested a rewrite/cleanup of the software viewer to address some of the issues with the old one. at the moment it is in the de.jreality.softwiever package in the src-soft-new dir. Here is a list of the most notable and noteworthy changes:

Except for the environment map ( a fast normal-CubeMap lookup anyone?) the VRviewer looks o.k. in software rastering now.

At the moment there is only a double rasterizer which is slightly slower than the old integer rasterizer (that used fixpoint arithmetic but was allways problematic with non normalized texture coordinates)

Some of the changes give slight performance penalties but in general it is still o.k. to try it you can set -Dde.jreality.scene.Viewer="de.jreality.softviewer.SoftViewer" to have only the new softviewer available in the (vr)viewerapp (or add a ":" separated list of others to have the choice in the viewerapp)

Timh 13:36, 11 Nov 2006 (CET)

Update: I also added support for othographic camera now.

Timh 11:58, 13 Nov 2006 (CET)

Clean up of this page

I've removed all topics older than one year; they can still be accessed on the following page: Talk-09.11.06.

Selection

At yesterday's (Nov. 8) meeting, we discussed some issues related to selection in ViewerApp class. I'm wondering if we should think about providing selection support at a lower level (that is, not connected as currently to the ViewerApp class), so that users could take advantage of selection mechanisms without being forced to use the ViewerApp class. I've had good luck myself with providing a static lookup method on my SelectionManager class: 
 public static SelectionManager selectionManagerForViewer(Viewer v) {};
which provides a mechanism for getting selection managers assigned to Viewer instances. The default behavior is that it looks in a hashmap to see if the viewer has a selection manager already; if not it allocates one and puts it into the table. This behavior could be overridden if we wanted to experiment with several viewers all sharing the same selection manager. In this way, a SelectionManager would then be available inside of Tool instances, since the Viewer instance is provided by the ToolContext class (which doesn't know about ViewerApp obviously). The current use of SelectionManager in ViewerApp could be easily changed to conform to this, by allocating the SelectionManager for the ViewerSwitch which belongs to the ViewerApp.

A second question related to selection arose regarding whether a Tool instance should be able to be included in a SceneGraphPath, as if it were a SceneGraphNode instance. I would favor such a strategy, since it fits in with being able to address top-level elements of SceneGraphComponents within a SceneGraphPath. Whether we want to extend SceneGraphPath to include finer level of detail is a separate issue which I won't address here.

Gunn 11:56, 9 Nov 2006 (CET)

Tool system, revisited

Steffen has addressed almost all the issues I raised in my original posting below "Questions on tool system". One thing that I still want to understand better is the avatar path. Until now I haven't understood why this has to be part of the global tool system that we provide to jReality users. Can someone provide me with a simple example of a tool that needs to have this avatar path provided from a global state, rather than have the tool itself placed in such a way that the desired path is available locally? :Gunn 09:58, 30 Aug 2006 (CEST)

I'm still not clear why this requires that the tool system knows about the avatar path. Why not put the tool mentioned above into the desired "avatar" node when you build the scene graph? I don't doubt that avatar is a reasonable concept; what I don't yet understand is why the tool system has to be aware of it. :Gunn 16:38, 20 Nov 2006 (CET)

Remarks on transparency

From my recent experiences using RenderMan, I've had some more thoughts about how jReality supports transparency. I've basically changed my mind about how to treat the alpha channel of colors. As far as possible, the "transparency" field in the appearance node should be used to control the transparency of the surface. To be exact: I think that the JOGL back-end and to a lesser extent the Renderman backend, are the only backends where this is an issue. I'd undertake to fix those backends should there be a general agreement that the alpha channel should be restricted in the manner outlined above.
Gunn 15:09, 9 Aug 2006 (CEST)

Questions on tool system

I've been trying to understand how the tool system works in the past few weeks. I've begun to get a picture of it, and it's clear that it is a very ambitious project that achieves some important aims. I'd like to understand better the following questions:
Gunn 13:33, 18 May 2006 (CEST)

Appearance inheritance mechanism

Gunn 10:13, 28 Mar 2006 (CEST)

Remarks on 3D/4D and non-euclidean signature

Gunn 13:32, 15 Mar 2006 (CET)

picksystem and other things

I added support for texture coordinates in the AABB and soft pick system. It basically works well but I found some bad results now and then in a samble app. wwwhere one can cint on the helicoid. This is eicher due to numerics in the interpolation or the pick is incorrect (I suspect the first possibility) so more tests need to be done. I refactored the Swing component as a texture oorange network into a bunch of classes. It is basically a Component that takes a Swing component and gives you an appearance and a tool to attach to the geometry in question. It uses texture coordinates if available (so curved panels are possible now) and projects the pick point on the x-y-plane otherwise (like the network did before). I changed the way mouse events are dispatched as well. they should correctly report enter,exit events now, since swing does all the work. Still the system has to prove that it is working on more complex guis. Timh 16:57, 13 Feb 2006 (CET)

some threading issues

I ran into an ugly thread problem (deadlock) when implementing the JTree: Changes to the tree must be done from inside the awt thread, so I tried to do a call like 
  EventQueue.invokeAndWait( reader )
in some sort of listener - i.e. when a tool sets a Transformation. But the event is generated with a write lock on the node, and the read operation of course needs a readLock...

While I tried to fix this problem, I figured out that the current thread-safety-state is very poor - we do not support concurrent readers! The childrenAccept(..) simply synchronizes the whole call - so no other thread can visit the graph.

Another problem is that there is no way to write from inside a visitor, in the "makeSubgraphPickableVisitor" I had to do the following: 

  visit(SceneGraphComponent sgc) {
    if (scg.getGeometry() != null && scg.getGeometry() instanceof IndexedFaceSet) 
      ((IndexedFaceSet)scg.getGeometry()).setGeometryAttributes(...);
  }

One way to fix that would be a childrenWriteAccept, that gets a writeLock before the visit is called (for all children), but I would prefer some way of specifying which node types the visitor wants to write.

Update: I started to get the core thread-safe. The new src is in cvs under src-core. Changes:

The Lock can change a writeLock into a readLock and back. So after all writes are done, the writeLock is changed into a readLock, and the (collected) events are distributed. So listeners can notify changes to different threads (i.e. the dispatch thread ;-). But there is still the need for writing from inside the event, this is handled as follows: The SceneEvent class has a method enqueueWriter( runnable ). After all listeners are informed, the lock is changed into a writeLock again and the (also collected) writers are executed. this repeats until no more writers are enqueued.

Generally all reads are surrounded by 

 startReader();
 try {
   return ...
 } finally {
   finishReader();
 }

and the same for write methods. (with start/finishWriter();) The finishWriter() in SceneGraphNode calls writingFinished() when the last nested writing is done. In this method subclasses will distribute their collected events, the lock is already a readLock.

The visitors just do the same, so concurrent reads are possible now. Also writing is possible from a visitor now:

Instead of calling 

 sgc.childrenAccept(visitor);
writing visitors call 
 sgc.childrenWriteAccept(visitor, writeTransformation, writeAppearance,
     writeCamera, writeLight, writeGeometry, writeChildren);
the writeSth are booleans whether a certain child type will be written. If a visitor writes on components, it must be invoked with 
 Scene.executeWriter(rootNode, ...);

Status: Currently all nodes except Camera and Transformation are done and seem to work fine.

Todo: Transformation + Camera! AppearenceEvent+Listeners need to be changed to report multiple changed attributes. AddOn: I mad the AABBPick Visitor write sn AABBTree into the ifs if there was none. and found that the childrenWriteAccept was to slow. GEtting a write lock for every geometry all the time is to expensive. Now I had to check in the Component if the tree is absent and decide to either visit or visit with write. It might be better if every node had a writeAccept(..) then one could decide in the read visit that one has to change a thing and call writeAccept with a new Visitor that performs the change. Or as I mentioned in the last meeting: have aa childrenWriteAccept that takes a conditional (an interface with a metthod that returns on a given sceneNode wether a write is necessary.Timh 17:39, 13 Feb 2006 (CET)

unsortet things while looking through the shaders

in the default shader makes no sense to me (plus software renderer, rendermann export etc. ) never responded to that.

Geometry factories

I finally converted almost all of my geometry creation code to use the factories. Based on this experience, here's some recommendations for these factories: Current problems:

Gunn 12:19, 14 Nov 2005 (CET)

Old topices

For older topics see Talk-09.11.06.

Gunn 11:21, 9 Nov 2006 (CET)