Re: [Flightgear-devel] Spiffy new panel gadget
Andy Ross writes: I should explain the problem a little better. What's happening is that there is no place to put a normal vector in the .ac file. The plib loader thus has to generate its own normals by averaging the normals of each polygon attached to a vertex. For vertices that are inside an object/texture, this works fine. But ones on the edge can't average in the normal of the polgon(s) that are on the other texture, as those are part of a different object in the .ac file. So what happens is that a vertex on one texture has a normal vector that is *different* from the normal of the same point on a different texture. This makes that polygon edge look sharp when lit. What's especially frustrating is that (1) I'm generating this file automatically, so I could export the normals explicitly if I wanted to, but the file format won't let me; and (2) it's a sphere! Generating normals is a ridiculously trivial operation -- they're just the coordinate of the vertex. Somewhere in simgear there is code to generate a plib sphere. It's adapted from the glu sphere code, but this code builds a sphere in a plib scene graph. We use it to build the moon and the sun I believe. That doesn't help you directly, but maybe if we extended the instrument xml so you can specify a primative and a texture and a placement and the animation variable hooks ... might not be too hard (?) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spiffy new panel gadget
Andy Ross wrote: + 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. Well, it spoiled the fun for me. FPS from 10-15 down to 1 fps :-( Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Spiffy new panel gadget
Andy Ross writes: + 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. 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. Sadly the SSG ASCII File Format only about 80-90% complete as it was intended as a 'partial debug dump' of the Binary SSG Format only. ie it gives the Vertices and Normals of the Leafs but doesn't do the other nodes. This could probably be added with a 'bit' of work. Note that with PPE you can 'Inspect' all of the graph so most of the code has been written just not 'colated' Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Spiffy new panel gadget
Andy Ross writes: + 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. We already do -- when you are inside the cockpit, the aircraft is in its own scene graph with its own clip plane; it's only when you're outside the the aircraft model has the same clip plane. + 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. The first thing to do is clamp on a brutal LOD (i.e. 1-2m), so that you're not paying the penalty in external view. + 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. The format does, I think, but plib doesn't use that information. The good news is that the AC3D format allows every surface in an object to have its own, separate UV mapping, so you don't have to split an object to use more than one projection from the same texture file; the bad news is that AC3D itself doesn't have a good UV editor. The mixed news is that you can use Blender with the AC3D export script to do complex texture mapping. 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 we'll have to stick with AC3D for now. I did some experimentation a while ago, and AC3D is the only format that worked acceptably for me in plib with textured models. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spiffy new panel gadget
Erik Hofman [EMAIL PROTECTED] said: Well, it spoiled the fun for me. FPS from 10-15 down to 1 fps :-( Erik Hmmm...that seems a bit extreme. The model as a whole is a lot more complex. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spiffy new panel gadget
I lied again:
The perl scripts that generated the ball are attached. The ball.pl
script spits out the .ac file, while balltex.pl generates the texture
Postscript in a very similar manner to the gauge stuff I posted
earlier. Pass it an argument of north/south/east/west/top/bottom to
tell it which texture to generate.
Oops.
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
Men go crazy in conflagrations. They only get better one by one.
- Sting (misquoted)
#!/usr/bin/perl -w
use strict;
# Output gadget
sub ac { print join(\n, @_), \n; }
# Axis contstants.
my ($X, $Y, $Z) = (1, 2, 3);
# How big?
my $RADIUS = 0.075; # grapefruit
# How many squares across is a face?
my $N = 4;
# Base coordinates. These should really be done differently. A
# better mechanism would be to arrive at each point as the center of
# two parents rather than assuming linearity over the square.
my @XCOORDS = ();
my @YCOORDS = ();
for(my $i=0; $i=$N; $i++) {
$XCOORDS[$i] = 2 * $i/$N - 1;
$YCOORDS[$i] = 2 * $i/$N - 1;
}
# Initialize the P array of points for a cube face in a single
# coordinate system. We'll get the others by swapping and inverting axes.
my @P = ();
for(my $i=0; $i=$N; $i++) {
for(my $j=0; $j=$N; $j++) {
my $x = $XCOORDS[$j];
my $y = $YCOORDS[$i];
my $z = 1;
my $norm = $RADIUS/sqrt($x*$x + $y*$y + $z*$z);
$x *= $norm;
$y *= $norm;
$z *= $norm;
$P[$i]-[$j] = [$x, $y, $z];
}
}
ac AC3Db;
ac 'MATERIAL BallSurface rgb 1 1 1 amb 0.2 0.2 0.2 emis 0 0 0 spec 0.5 0.5 0.5
shi 10 trans 0';
ac OBJECT world;
# The directions specified are the directions displayed *on* the
# faces, not the directions of the faces from the center of the cube
# (that is, the south-facing cube face says north.
ac kids 6;
doface(north, $Y, $Z, $X);
doface(south, -$Y, $Z, -$X);
doface(east, $X, $Z, -$Y);
doface(west, -$X, $Z, $Y);
doface(top, $Y, -$X, $Z);
doface(bottom, $Y, $X, -$Z);
sub sgn { shift() 0 ? -1 : 1 }
sub doface {
my $name = shift;
my $xidx = shift;
my $yidx = shift;
my $zidx = shift;
# Extract the signs and correct the indices
my $xsgn = sgn($xidx); $xidx = abs($xidx);
my $ysgn = sgn($yidx); $yidx = abs($yidx);
my $zsgn = sgn($zidx); $zidx = abs($zidx);
my @idxtmp = ();
$idxtmp[$xidx] = $xsgn * 1;
$idxtmp[$yidx] = $ysgn * 2;
$idxtmp[$zidx] = $zsgn * 3;
$xidx = $idxtmp[1];
$yidx = $idxtmp[2];
$zidx = $idxtmp[3];
$xsgn = sgn($xidx); $xidx = abs($xidx) - 1;
$ysgn = sgn($yidx); $yidx = abs($yidx) - 1;
$zsgn = sgn($zidx); $zidx = abs($zidx) - 1;
# Object header
ac OBJECT poly;
ac name \$name\;
ac texture \$name.rgb\;
# Print out the vertex list
my $numvert = ($N+1)*($N+1);
ac numvert $numvert;
for(my $i=0; $i=$N; $i++) {
for(my $j=0; $j=$N; $j++) {
my $p = $P[$i]-[$j];
my $x = $xsgn * $p-[$xidx];
my $y = $ysgn * $p-[$yidx];
my $z = $zsgn * $p-[$zidx];
# Final complication: plib's AC3D loader munges the axes.
ac sprintf(%.4f %.4f %.4f, $x, $z, -$y);
}
}
# And now a triangle list. This is identical across faces.
# The vertex indices go left to right, then bottom to top:
# 12 13 14 15
# 8 9 10 11
# 4 5 6 7
# 0 1 2 3
my $numsurf = 2*$N*$N;
ac numsurf $numsurf;
for(my $i=0; $i$N; $i++) {
for(my $j=0; $j$N; $j++) {
# Vertex indices (bottom/top, left/right)
my $bl = ($N+1)*$i + $j;
my $br = ($N+1)*$i + ($j+1);
my $tl = ($N+1)*($i+1) + $j;
my $tr = ($N+1)*($i+1) + ($j+1);
# Texture coordinates
my $texb = sprintf %.3f, $i / $N;
my $text = sprintf %.3f, ($i+1) / $N;
my $texl = sprintf %.3f, $j / $N;
my $texr = sprintf %.3f, ($j+1) / $N;
if($i+$j 0x01) {
# Bottom right triangle
ac SURF 0x10;
ac mat 0;
ac refs 3;
ac $bl $texl $texb;
ac $br $texr $texb;
ac $tr $texr $text;
# Top left triangle
ac SURF 0x10;
ac mat 0;
ac refs 3;
ac $tr $texr $text;
ac $tl $texl $text;
ac $bl $texl $texb;
} else {
# Bottom left triangle
ac SURF 0x10;
ac mat 0;
ac refs 3;
ac $tl $texl $text;
Re: [Flightgear-devel] Spiffy new panel gadget
Jim Wilson wrote: Andy Ross wrote: What might be easier, though, is allowing for a optional 6-element vertex line that included the normal. We should be able to load into ac3d. But if we embedded commands into the name tags we'd be ok. Ah, I see what you're saying. You're right, your idea is better. I thought that doing it as a namespace issue would require big surgery to the loader, but it looks like the code is already there. Looking at the plib source, this should be happening already. The flatten code in ssgOptimizer is already designed to collapse object hierarchies into a single vertex array, and it is also where the normal averaging happens. So it should be doing this for us automatically... I can't quite see how it avoids flattening named sub-objects. It doesn't flatten ssgTransform objects with user data, but I can't see where the user data is coming from. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spiffy new panel gadget
Andy Ross writes: You know, that's not a bad idea. What might be easier, though, is allowing for a optional 6-element vertex line that included the normal. For this application, this is simpler since we already know the normal. Code changes to plib would be limited to detecting the new format, storing the normal during parsing, and skipping the normal generation step. It's probably a crap shoot as to whether they'll accept the change or not, though. It's a hack to a proprietary format that we don't control. Even if we make it backwards-compatible, it's still not AC3D format anymore. For now, Andy, why not just generate a single object containing all of the surfaces, rather than 6 separate objects? Then plib will have less trouble with the normals. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spiffy new panel gadget
David Megginson [EMAIL PROTECTED] said: Andy Ross writes: You know, that's not a bad idea. What might be easier, though, is allowing for a optional 6-element vertex line that included the normal. For this application, this is simpler since we already know the normal. Code changes to plib would be limited to detecting the new format, storing the normal during parsing, and skipping the normal generation step. It's probably a crap shoot as to whether they'll accept the change or not, though. It's a hack to a proprietary format that we don't control. Even if we make it backwards-compatible, it's still not AC3D format anymore. For now, Andy, why not just generate a single object containing all of the surfaces, rather than 6 separate objects? Then plib will have less trouble with the normals. Only one texture per object. Is that a problem? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spiffy new panel gadget
On Friday 21 June 2002 8:41 am, Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: Well, it spoiled the fun for me. FPS from 10-15 down to 1 fps :-( Erik Hmmm...that seems a bit extreme. The model as a whole is a lot more complex. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel FWIW I'm getting 55-120 fps depending on the terrain complexity in the forward view. Geforce2, Celeron 700 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Spiffy new panel gadget
Andy Ross writes: Jim Wilson wrote: Andy Ross wrote: What might be easier, though, is allowing for a optional 6-element vertex line that included the normal. We should be able to load into ac3d. But if we embedded commands into the name tags we'd be ok. Ah, I see what you're saying. You're right, your idea is better. I thought that doing it as a namespace issue would require big surgery to the loader, but it looks like the code is already there. Looking at the plib source, this should be happening already. The flatten code in ssgOptimizer is already designed to collapse object hierarchies into a single vertex array, and it is also where the normal averaging happens. So it should be doing this for us automatically... I can't quite see how it avoids flattening named sub-objects. It doesn't flatten ssgTransform objects with user data, but I can't see where the user data is coming from. The best example I know of for ssgLoaderOptions() 'user_data' feature is Steve's TuxKart game. see tuxkart_main in tuxcart.cxx to set this feature up and loader.cxx for several examples You can also ask questions over on the PLib list :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
