Overlays/Interface Panels - best way?

Engines, Libraries and Tools Java 3D
#1

Apologies for cross-post with the J3D-INTEREST mailing list, but I got no responses there and I could use some advice on this.

Following on from my question on updateable textures, I have managed to sort that part out but I don’t really know what to do next.

Currently I have got some planes with dynamically updated textures attached as platformgeometry on my viewplatform. That works fine but I’m not sure a) how to move forward and b) whether this is the best way of doing things at all.

If I am continuing with this approach what is the best way to texture more extensive components- the square texture thing is an obvious limitation - if I have a rectangular shape should I be creating several small textures to match it as closely as I can (and if so, do I have to create a separate plane for each texture?) or should I be creating a single larger texture and fitting it using texture coordinates?

Alternatively, am I completely barking up the wrong tree by using geometry in the scene when there is some really clever way of getting around this altogether?

I know there are a few libraries to do this type of thing but I’m trying to better myself by understanding how it all works…

#2

Breakfast, By updating the texture on the platform geometry what effect are you after? Are you creating a dashboard of sorts?

The (power of 2) square texture limitation is a pain. The next version of OpenGL no longer has that limitation so maybe we should see if J3D 1.4 could include that support. I have taken the approach of fitting the desired texture in the smallest possible power of 2 size and adjusting the texture coordinates. While I have not tried it, the texture unit support allows you to apply multiple textures with different texture coordinates. You might be able to save some memory depending on the shape of the texture.

Mike

#3

That’s it- the typical user status monitor stuff- you have 50% health and this way is north. I just really couldn’t tell whether one big texture on one piece of geometry or lots of smaller textures on lots of smaller bits of geometry would be better and then when I was searching the Java-3d archives for more on this I was finding people talking about writing directly to the raster (or something like that- once you get into the close detail of graphics programming I get a bit lost) and I was wondering if that might be a better way to work.

I guess the best way to find out is to try both and do a bit of testing on them to see what is more efficient…

#4

Breakfast, You might want to have a look at using javax.media.j3d.J3DGraphics2D (drawAndFlushImage method). I haven’t used it but may be an option for you.

Mike

#5

Hi

Drawing using the J3DGraphics2D is very slow. I had this same issue my self and went down the drawing onto planes with dynamic textures. The code is still around in the Early access libraries section on the newdawn website, but it’s not been looked at or touched for some time. If nothing else it might be a usefull reference

HTH

Endolf

#6

I have just gone through the same exercise, since the J3DGraphics2D performance was supposed to have improved with Java3D 1.3.2.

However, I have found that, while better, it is still nowhere near the performance of using textures attached to the viewport. Here’s some performance results that I found, using a fairly simple scene capped at 60 fps, with a WakeupOnElapsedFrames(0) to force rendering every frame, using J3DGraphics2D vs. textures.

I tried one approach using a separate BufferedImage for each overlay, and called drawAndFlush() for each one, and another approach where I used one combined BufferedImage with one drawAndFlush() operation.

  1. No overlays: 60 fps
  2. J3DGraphics2D, Java3D 1.3.1, using separate BufferedImages: 1-2 fps
  3. J3DGraphics2D, java3D 1.3.2, using separate BufferedImages: 5-6 fps
  4. J3DGraphics2D, using combined BufferedImage for all overlays: 4-5 fps
  5. j3d.org.Overlay library, with separate translucent Overlays: 56-57 fps

I have not tried using one texture for all of the overlays, since I was convinced after step 3 that textures was the way to go.

I believe I read somewhere (on j3d.org?) that the reason using textures is so much faster is because of the video architecture – the 3D scene gets rendered on the video card, then J3DGraphics2D pulls the entire scene over the bus into main memory, then you draw on it, then you send the updated screen image back to the video card. If you are using textures then the whole thing is done on the card and you only incur the extra overhead when updating the textures. So static textures are the fastest. And drawing Swing-like visual updates as you move the mouse around is the slowest. Also, texture size makes a huge difference, possibly O(n^2)?

#7

it’s a long time ago but i tried the same, using J3DGraphics2D. And the framerates dropped from 100 to 40 or so. It’s a big lost but not as drastic as your experience. (I used j3d dx version on win)

#8

I have had much success with the extension of Canvas3D, overriding postRender(). I have also solved the flickering issue. Using this method my (complex scene) fps drops from 45 without overlay to about 40±3 with overlay, behaviors and timers, and my very un-optimized drawing code does a lot of scaling calculations:

class DrawOnCanvas3D extends Canvas3D
{
private J3DGraphics2D j3dg2d;
private int width = 512, height = width;
private BufferedImage bufim;
private Graphics2D g2d;

public DrawOnCanvas3D(GraphicsConfiguration gc)
{
    super(gc);
    bufim = new BufferedImage(width, height, BufferedImage.TYPE_4BYTE_ABGR);
    g2d = bufim.createGraphics();
    j3dg2d = this.getGraphics2D();
}

public void postRender()
{
    g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.CLEAR, 0.0f));
    g2d.fillRect(0,0,width,height);
    g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, 1.0f));
    g2d.setColor(Color.WHITE);

/---->
g2d.drawingStuffHappensHere(…)
<----/

    j3dg2d.drawAndFlushImage(bufim, 0, 0, this);
}

}