JOGL and Resizing Windows

I'm not sure if I'm the only person who's not using JOGL to do animation, but I seem to have a problem where when I resize a JOGL window, it fails to update its screen correctly. Most people don't encounter this because if they constantly update their screen inside an animation loop, any update failures will correct themselves during the next pass through the animation loop. A quick search through Google brings up nothing.

What happens is that if I use the November 19th build of JOGL, when I resize the window, I get a blank white screen. When I resize it again, I get my image displayed correctly again.

I suspect that the problem has something to do with double-buffering after a resize. Here is my evidence:

a) when I do successive resizing, it alternates between being ok and not being ok
b) after I do a resize, cover the window, and uncover the window, the window looks fine again
c) if I create a single-buffered OpenGL context, JOGL keeps dumping stack traces to the console
d) The following bit of code looks suspicious:
if (autoSwapBuffers && !isReshape) {swapBuffers();}

Still, when I trace through the execution of the code, everything seems to trigger correctly, so I suspect that maybe I'm just doing something incorrectly in OpenGL or elsewhere. If I force an extra buffer swap after a reshape, everything does seem to work correctly (the white screen still shows, but it's quickly overwritten during the successive call to display). Perhaps it's a driver problem. I should try this on a different machine.

X3D and the Importance of High Quality Specifications

This isn't a real post but more of a rant session about the quality of the X3D specification. This spec is of mediocre quality at best. It's quite clear that they revised the spec many times and forgot to clean up references to old revisions. For other parts of the spec, they seemed to be describing an existing implementation as opposed to specifying how new implementations should behave (i.e. they leave out important details). Various parts of the spec are inconsistent or confusing. Worst of all, some parts of the spec give off the impression that they've NEVER BEEN IMPLEMENTED.

I've only tried to implement a very small amount of the specification so far, but here are various problems I've seen so far:

1. A lot of the example interfaces for the Java language bindings are inconsistent with other parts of the specification or are simply wrong.

2. The Java language bindings have clearly never been implemented or tested.

3. Default values are defined for several field instances when they are simply the same as the defaults for fields themselves

4. They never really make it clear what their notation for node fields are

5. Various inherited fields are listed repeatedly over and over again

I suppose it's a little worse for me because I'm autogenerating code based on the specification, so things that would be glossed over by someone implementing the specification by hand really cause problems for me. Oh well. So far, I haven't hit any part of the spec that was so outrageously wrong that I couldn't figure out what they had intended, so maybe things aren't so bad after all.

X3D Ambitions

After spending more time trying to understand the X3D spec, I think I've decided that it is simultaneously less ambitious and more ambitious than I had expected. I had initially thought that X3D intended to define specifications for a lot of the annoying 3D programming issues like file exchange, scene graphs, etc. This way, programmers could just use some X3D components instead of having to code their own lower layer 3d code. Based on what I had read from the spec and about the history of X3D, I thought that that's what X3D was for. I'm a little skeptical of that idea, but it does sound intriguing. I'm actually a little disappointed that this isn't wasn't X3D was aiming to do. In fact, X3D seems to be just a standard for a 3d media player/browser. They've essentially designed a file format for X3D media and an API for talking with X3D browsers. If X3D were a database, the X3D specification would describe the file format of the database, an RPC framework for communicating with the database, and a general description of how the database should behave. This is an ambitious vision, but it isn't as generally useful as having a bunch of lower-level components. Hopefully when the 3D Industry Forum comes out with their competing spec, it'll be possible to compare which approach is more useful. I suppose that it's like the difference between white-box and black-box inheritance. Oh well.

In any case, generating code using XSLT seems to work pretty well. It's a little verbose, and you have to watch for those <> characters in the code, but I've been pretty satisfied so far. Hopefully, if all goes according to plan, I'll have a rudimentary partial implementation of a few nodes from the SAI layer of X3D by Monday. Then I can actually start cobbling together a renderer and parser.

Starting with X3D

So, I somehow committed myself to making a simple X3D browser for mobile devices, but it's really hard to figure out where to start. I've been browsing the specification for several days now, and it's just not really sinking in. Usually, the reference implementation (xj3d) would be the normal place to start, but it's really a VRML browser with a thin veneer of X3D on top of it. In any case, most of xj3d seems to be hand-coded, but the specification looks really amenable to automatic generation, which is the route I want to take.

In order to code up a browser, you need a simple 3d engine first. Since X3D defines a scene graph API, it seems like that working on that API would be an ideal place to start (since one can use a scene graph as the base for a 3d engine), but the more I read about the X3D scene graph API, the more I realize that it's inappropriate for doing any sort of rendering from it. Plus, the interface for getting a browser instance seems cumbersome to code up as well. Still, I suppose it's as good a place to start as any.

For the code generator, I was originally thinking of coding something up in Java, but I think I might make an attempt at putting something together in XSLT. I'm not sure if it'll work, but it's always good to use existing standards, so I suppose it's worth a try. Of course, XSLT doesn't support generating multiple output documents from a single input document, so I'll still have to write some sort of coordinator or something.

I guess I'll start with something simple by auto-generating the exception classes. Already, there are some pecularities in the spec, because initially they define a bunch of abstract language-independent exceptions and then later in the spec, they decide that for the Java version, they'll use a different set of exceptions using a completely different naming scheme. This is actually sort of annoying; I think it's a bug in their spec.

Understanding X3D

For the past few months, I've been trying to wrap my head around this whole X3D thing. I haven't really done anything with it yet, but I have read a lot of documentation, and it just isn't clicking with me.

I think the problem is that when most people decide to learn X3D, what they're looking for is a nice universal file format for 3d models. My impression is that to work with 3d models now, you have to go about downloading various SDKs describing how to work with certain propriety model formats that are outputted by programs that you could never afford. Developers want some sort of standard file format that they can work with instead, and ideally X3D would be this standard. What they actually get is VRML encoded in XML.

Now VRML sort of puttered out a few years back, and I suspect that this would probably explain the lukewarm reception of X3D right now. Most people that I've talked to have either never heard of X3D or simply don't care.

In any case, because of X3D's VRML past, it actually does three things:

FILE FORMAT

X3D describes a way of encoding 3d geometry in XML. This part of the specification is what people actually want X3D to do.

SCENE GRAPH

I think X3D also defines an API for storing and manipulating scene graphs in memory. In fact, the file format is simply a way of serializing the scene graph to a file. I'm a little ambivalent about this. Admittedly, every time anyone wants to do anything in graphics, they have to put together some sort of scene graph code. Each year, thousands of computer science students taking graphics course have to put together a new scene graph framework so that they can do some 3d work. And anytime a company decides to create a 3d API (e.g. Java3d or JSR184), they always decide to create their own scene graph API to go with it. So I suppose it would be nice if everyone could agree on a single scene graph API. On the other hand, the first thing that people ask upon encountering a scene graph API is "how do I make it show a bunch of triangles on the screen like in OpenGL," so maybe a standardized scene graph API isn't all that useful an abstraction. After all, you don't see people creating a bunch of objects for representing shapes and geometry of 2d scenes. I guess the thing that causes me the greatest concern is the fact that all the X3D implementations that I've looked at (which is, admittedly, only two) take the X3D scene graph and immediately convert it to a different scene graph format before doing anything with it. This includes the X3D reference implementation! If the scene graph API were any good, then there really shouldn't be any reason to convert it to a different representation, right?

PLATFORM

Because of its VRML roots, X3D similarly tries to provide a complete "platform" for doing 3d applications. In other words, X3D seems to provide enough language bindings, scripting support, interactivity features, event models, etc. that X3D can be used as the basis for a complete 3d application. Personally, I think this is the most dubious aspect of X3D because understanding and implementing all of these features is really hard, and people who are only interested in a universal 3d file format really don't care about this stuff. I think it may be possible to make a compliant X3D implementation that ignores all of the platform stuff, but I'm not entirely sure yet, and in any case, I find the X3D documentation extremely hard to read because of all the references to these platform features.

So I guess the primary question is whether X3D fails as a file format because it tries to do many other things as well. Frankly, I don't know. I have committed myself to doing some work with X3D though, so hopefully I'll be able to figure this out as I dig deeper into the specification.

First Post

Well, I've been thinking of doing some blogging for a long time, but every time I was about to start, I kept getting this horrible feeling that my blog would simply end up being a summary of stuff I read on Slashdot.

I occasionally do some coding though, and sometimes, I hit a snag that I'm sure that someone else has encountered before, but I still have to spend hours and hours researching answers. Afterwards, I can't help but wish that other people had documented their experiences, so that I wouldn't have to waste hours redoing what they've already done.

So skipping right to the point, this blog will be a summary of various issues that I've encountered during coding and the solutions that I found worked.