Andy Ross <[EMAIL PROTECTED]> said: > You ever have one of those days where you think of a cute idea, > casually code it up to try it, and discover that it works better than > you'd have ever expected? It's been a good day. Check out A-4 panel.
Ha! I've been working on the same thing. Looks like you've gotten a lot further with the texture and animation though. > It isn't quite done, clearly: > > + It's so close to the near clip plane that the precision errors cause > nasty jittering; this happens to the rest of the cockpit geometry > too. Honestly, I think this is probably unavoidable. We should > really look at solutions for drawing the cockpit into a separate > depth range from the terrain. On the other hand, it's kinda nifty > to be able to zoom in to the cockpit in the outside view and see > thins thing on the panel. I noticed that as well. AFAIK there wouldn't be a problem with drawing the cockpit that way, but I'm not clear that it would change much. In any case I don't find it that distracting, and its really the combo with the 2D panel that makes it most noticable. > + The cockpit geometry is kind of whacked. :) It wasn't really > intended for viewing at 1m, so it doesn't quite fit. I had to > shrink the ball down to about 4 inches in order to make it look > right in combination with the virtual cockpit's default plane, which > is itself kind of whacked (I know, I know, I really need to fix > that). Again, I think we should consider allowing for separating a > cockpit scene graph from the aircraft model and terrain. The cockpit has really just been roughed in. Actually I think that 4 inches was about right for that instrument. The bezel makes it about 6 x 6 total. Anyway I need to reorient the panel object in the a4 model as well. It is sloped and should not be. > + We need an enclosure for it, with roll indicators, cross hairs and a > turn ball before it'll be truly useful. I'm hoping someone with > more 3D skill than I is willing to try to make the box. :) I've got a three layer bezel on the one I was working on, instead of putting time into the textures like you did :). If you want I'd be glad to pick that up this evening. > + At 192 triangles and 6 128x128 textures, this is an expensive > instrument. There were no significant effect on frame rate on my > machine, but we can't be sprinkling gadgets like this around the > panel without hurting someone. Mine was much more expensive than that with three 256x256 textures. In my opinion it deserves the investment because of its shape and size. > + It's exposed some strange behavior in the lighting code -- the > specular highlights at night (I know, specular highlights at night?) > are way to bright, and there is an odd "popping" behavior as the > vertices enter shadow. I think this might be a bug in plib; I > haven't investigated. Good question. A while back I experimented a bit and found something not working quite right, but didn't trace it to plib. It seemed at the time that the ac3d support in plib may not be quite complete. > + This one really annoys me: the AC3D file format apparently doesn't > allow you to specify normals explicitly, it wants to calculate them > itself. This works fine for the vertices inside the texture, but > texture boundaries show up as sharp edges because the polygons in > separate objects don't share their coincident vertices. This is not an ac3d file format problem as it does not show up on converted models. Been thinking of a couple utilities that could be used to improve ac3d output (I know David is going to suggest blender :-)). One thing that would go a long way to fixing these issues is more control over the texture mapping. The data in the ac3d file format is per polygon, but the ac3d program only does texture operations per object, and will not allow mapping per poly. So if you could construct a single object for the sphere (as it should be done) and apply the textures per poly (and map them in relation the polygon's normal instead of the three planes supported) then the weird edges will go away. Knowing this problem existed I took a slightly different approach, using a square meshed sphere. This resulted in the same problem around the equator of the sphere, but maybe slightly less noticable: http://www.spiderbark.com/fgfs/attitude-ball.png > Combined with the specular highlight issue, this can look very strange. > Is there a better file format? I know SSG has a native one. This > sounds great, but I couldn't find an ounce of documentation on it, > even in the code that parses it. I think that most of what we would need is supported in the ac3d format. The most difficult issues involve the ac3d program itself. Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
