Re: [Flightgear-devel] Fixing fgfs-construct crashes
I think the solution to this whole issue is to bring fgfs-construct .btg
generation closer to how the genapt works - keeping the material
information around with each poly through the clipping process.
Hi Peter,
I thought that was already the case? I was fooling around the other day,
modifying the BTG loader to use a material definition for each feature
(fan/strip/triangle), thus loading a different texture from the texture-set
instead of only one per tile. Really the only modification I made was to store
the geometry along with the material while loading, instead of loading a
material and then storing all features with that material in the same bin.
That seemed to bring the performance down to a crawl (to be expected since
otherwise this code would probably have been there from day 1). If it's any
use, I'll attach here a diff of my experiments.
Cheers,
Adrian
diff --git a/simgear/scene/tgdb/obj.cxx b/simgear/scene/tgdb/obj.cxx
index d080ff3..ba56c0e 100644
--- a/simgear/scene/tgdb/obj.cxx
+++ b/simgear/scene/tgdb/obj.cxx
@@ -68,7 +68,7 @@
using namespace simgear;
-typedef std::mapstd::string,SGTexturedTriangleBin SGMaterialTriangleMap;
+typedef std::multimapstd::string,SGTexturedTriangleBin SGMaterialTriangleMap;
typedef std::listSGLightBin SGLightListBin;
typedef std::listSGDirectionalLightBin SGDirectionalLightListBin;
@@ -190,7 +190,7 @@ struct SGTileGeometryBin {
}
static void
- addTriangleGeometry(SGTexturedTriangleBin triangles,
+ addTriangleGeometry(SGMaterialTriangleMap triangleMap, std::string material_name,
const std::vectorSGVec3d vertices,
const std::vectorSGVec3f normals,
const std::vectorSGVec2f texCoords,
@@ -203,11 +203,11 @@ struct SGTileGeometryBin {
// If the normal indices do not match, they should be inmplicitly
// the same than the vertex indices. So just call ourselves again
// with the matching index vector.
- addTriangleGeometry(triangles, vertices, normals, texCoords,
+ addTriangleGeometry(triangleMap, material_name, vertices, normals, texCoords,
tris_v, tris_v, tris_tc, tcScale);
return;
}
-
+SGTexturedTriangleBin triangles;
for (unsigned i = 2; i tris_v.size(); i += 3) {
SGVertNormTex v0;
v0.vertex = toVec3f(vertices[tris_v[i-2]]);
@@ -223,10 +223,11 @@ struct SGTileGeometryBin {
v2.texCoord = getTexCoord(texCoords, tris_tc, tcScale, i);
triangles.insert(v0, v1, v2);
}
+triangleMap.insert(std::pairstd::string, SGTexturedTriangleBin (material_name, triangles));
}
static void
- addStripGeometry(SGTexturedTriangleBin triangles,
+ addStripGeometry(SGMaterialTriangleMap triangleMap, std::string material_name,
const std::vectorSGVec3d vertices,
const std::vectorSGVec3f normals,
const std::vectorSGVec2f texCoords,
@@ -239,11 +240,11 @@ struct SGTileGeometryBin {
// If the normal indices do not match, they should be inmplicitly
// the same than the vertex indices. So just call ourselves again
// with the matching index vector.
- addStripGeometry(triangles, vertices, normals, texCoords,
+ addStripGeometry(triangleMap, material_name, vertices, normals, texCoords,
strips_v, strips_v, strips_tc, tcScale);
return;
}
-
+SGTexturedTriangleBin triangles;
for (unsigned i = 2; i strips_v.size(); ++i) {
SGVertNormTex v0;
v0.vertex = toVec3f(vertices[strips_v[i-2]]);
@@ -262,10 +263,11 @@ struct SGTileGeometryBin {
else
triangles.insert(v0, v1, v2);
}
+triangleMap.insert(std::pairstd::string, SGTexturedTriangleBin (material_name, triangles));
}
static void
- addFanGeometry(SGTexturedTriangleBin triangles,
+ addFanGeometry(SGMaterialTriangleMap triangleMap, std::string material_name,
const std::vectorSGVec3d vertices,
const std::vectorSGVec3f normals,
const std::vectorSGVec2f texCoords,
@@ -278,11 +280,11 @@ struct SGTileGeometryBin {
// If the normal indices do not match, they should be implicitly
// the same than the vertex indices. So just call ourselves again
// with the matching index vector.
- addFanGeometry(triangles, vertices, normals, texCoords,
+ addFanGeometry(triangleMap, material_name, vertices, normals, texCoords,
fans_v, fans_v, fans_tc, tcScale);
return;
}
-
+SGTexturedTriangleBin triangles;
SGVertNormTex v0;
v0.vertex = toVec3f(vertices[fans_v[0]]);
v0.normal = normals[fans_n[0]];
@@ -299,6 +301,7 @@ struct SGTileGeometryBin {
triangles.insert(v0, v1, v2);
v1 = v2;
}
+triangleMap.insert(std::pairstd::string, SGTexturedTriangleBin (material_name, triangles));
}
SGVec2f getTexCoordScale(const
[Flightgear-devel] Announce: AeonWave 2.1 for Linux available
Hi, On Mon, 2011-11-07 at 12:53 +0100, Erik Hofman wrote: Some of you might already be aware of the fact that have been developing a 3D audio library for quite some time. Now is the time to call for a larger group of beta testers. The software is a replacement for OpenAL on linux and consists of two components: 1. the AeonWave Audio eXtentions library (or AeonWave for short). 2. an OpenAL emulation layer library. This is an update to inform everyone that AeonWave version 2.1 has officially been released at: http://www.adalin.com The Lite version is still (and will always be) royalty-free and the OpenAL layer is released under the terms of LGPL v3. Unfortunately I seemed to have goofed with the naming of RPM packages so Redhat/Fedora users might need to remove the beta install prior to installing the official version, sorry for that. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Terrain textures
Hi everybody, I have been doing recently some terrain textures experiments, mainly using aerial imagery from USGS and some personal photographs. I have managed to get a number of high resolution textures, and was wondering what the official policy is regarding terrain, and whether they would be eligible to be added to the main repository as is, or whether there is an alternative repository just for texture work. This forum thread contains screenshots of some of these new textures: http://www.flightgear.org/forums/viewtopic.php?f=5t=14254 Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing fgfs-construct crashes
I think the solution to this whole issue is to bring fgfs-construct .btg generation closer to how the genapt works - keeping the material information around with each poly through the clipping process. Ignore my previous e-mail on this issue, I misread the each poly part. Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain textures
Hi Adrian I think quality textures like yours goes directly to the main repo ? On the other hand I heared there is probably central scenery repo coming up (a separate repository and/or database). Maybe also for developing textures and to store origins or base material ? Green as I am I started such a database once myself (landcovertex). But without success, it needs to be close to the main project and at least 2-3 people working there. Textures can go from there to the main repo when texture packs are ready, when textures are classified and when changes to materials.xml are applied. I might be wrong, but in my point of view changing one single texture makes almost no sense for world scenery. And Git, images, heavy blobs ! ... as you mentioned once yourself, looking to texture blobs with git does not make a lot of sense. Thats why I still propose a texture developing database/gallery where main work is done, beside of a repository. Cheers, Yves Am 22.11.11 12:04, schrieb Adrian Musceac: Hi everybody, I have been doing recently some terrain textures experiments, mainly using aerial imagery from USGS and some personal photographs. I have managed to get a number of high resolution textures, and was wondering what the official policy is regarding terrain, and whether they would be eligible to be added to the main repository as is, or whether there is an alternative repository just for texture work. This forum thread contains screenshots of some of these new textures: http://www.flightgear.org/forums/viewtopic.php?f=5t=14254 Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain textures
Hi Yves, The issue here is that some of these textures are really large, and thus have the potential to limit performance for users with lower-end machines. Thus, I'm interested in guidelines/policies regarding texturing the terrain, what sizes are recommended or usable etc. I also agree about about having a unified texture scheme (or more, to suit different tastes/seasons/regions). Cheers, Adrian On Tuesday, November 22, 2011 14:23:09 HB-GRAL wrote: Hi Adrian I think quality textures like yours goes directly to the main repo ? On the other hand I heared there is probably central scenery repo coming up (a separate repository and/or database). Maybe also for developing textures and to store origins or base material ? Green as I am I started such a database once myself (landcovertex). But without success, it needs to be close to the main project and at least 2-3 people working there. Textures can go from there to the main repo when texture packs are ready, when textures are classified and when changes to materials.xml are applied. I might be wrong, but in my point of view changing one single texture makes almost no sense for world scenery. And Git, images, heavy blobs ! ... as you mentioned once yourself, looking to texture blobs with git does not make a lot of sense. Thats why I still propose a texture developing database/gallery where main work is done, beside of a repository. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announce: AeonWave 2.1 for Linux available
Congrats on the release Erik! Does your new sound system or OpenAL itself allow you to specify the origin of a sound as an x/y/z offset from a central point? tnx. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announce: AeonWave 2.1 for Linux available
On Tue, 2011-11-22 at 08:10 -0800, Gene Buckle wrote: Congrats on the release Erik! Thanks! Does your new sound system or OpenAL itself allow you to specify the origin of a sound as an x/y/z offset from a central point? AeonWave allows for multiple sounds with an offset to a center point of an audio-frame. Moving or rotating the audio-frame influences the position and orientation if all registered sound emitters. OpenAL only allows it by using a simgear SampleGroup .. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announce: AeonWave 2.1 for Linux available
On Tue, 22 Nov 2011, Erik Hofman wrote: On Tue, 2011-11-22 at 08:10 -0800, Gene Buckle wrote: Congrats on the release Erik! Thanks! Does your new sound system or OpenAL itself allow you to specify the origin of a sound as an x/y/z offset from a central point? AeonWave allows for multiple sounds with an offset to a center point of an audio-frame. Moving or rotating the audio-frame influences the position and orientation if all registered sound emitters. So theoretically, you could locate a sound emitter at a tire contact point? Neat. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announce: AeonWave 2.1 for Linux available
On Tue, 2011-11-22 at 08:53 -0800, Gene Buckle wrote: Does your new sound system or OpenAL itself allow you to specify the origin of a sound as an x/y/z offset from a central point? AeonWave allows for multiple sounds with an offset to a center point of an audio-frame. Moving or rotating the audio-frame influences the position and orientation if all registered sound emitters. So theoretically, you could locate a sound emitter at a tire contact point? Neat. :) Yep. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain textures
Am 22.11.11 15:06, schrieb Adrian Musceac: Hi Yves, The issue here is that some of these textures are really large, and thus have the potential to limit performance for users with lower-end machines. Thus, I'm interested in guidelines/policies regarding texturing the terrain, what sizes are recommended or usable etc. I also agree about about having a unified texture scheme (or more, to suit different tastes/seasons/regions). Hi Adrian The old policy for sizes in PNG format was (Erik, please correct when I am wrong): - 256 x 256 Pixel size for lowest resolution in folder Terrain - 512 x 512 Pixel size for higher resolution in folder Terrain.high - 1024 x 1024 Pixel size for higher resolution in folder Terrain.high, for use with my former transition, forest, rock, shrubcover shaders/textures, probably also for shaders from Frederic, i.e. urban shader I think the new work from Emilian/Vivian needs some new policy for the .dds files. I see formats up to 2048 x 2048 pixel size. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain textures
While we're on the subject of texture size, I'll expand a bit on the background issues: First, there are a couple of technical limitations: power of two sizes, and a maximum texture size of 4096x4096. Getting the technical part out of the way we come to the tricky part. My opinion is that texture size depends very much on the amount of detail that one wishes to provide in the texture, and by the area covered by the texture (the famous xsize ysize tags). One aspect of this is how do the textures look up close. This one's easy to determine dividing the pixel size by the value in the tags. So let's say we have a texture 512x512px that we consider should map a 1024x1024 meters area. Right away we see that a pixel would end up covering a 2x2m area. It's not for me to decide if that's good or bad. This is not so important on textures with general wide features like grass, savanna etc, but it becomes a problem on textures that contain isolated features, for which we know the size from experience, like trees, houses, roads. If these features are present in textures, they'll give false visual cues if they're not scaled properly. Let's take a narrow road for example: it's about 7m wide, you spot one on the ground while flying your Cub and decide to land on it, you do so with some dificulty, and when landed you realize the road is as wide as a freeway. Or you need to do an emergency landing in a field, with no working instruments, and you take as reference that lonely house you noticed there, you land further than expected, in a ditch, as the house was scaled up twice in the texture, and gave you the impresion you're twice as low as you were. For these textures, I think there should be given as much consideration to their scaling, as for how they look and how big they are. To sum it all up: - size should be stricly a power of two. - maximum texture size is 4096x4096 px, though preferred maximum size would be 2048x2048. - size should depend on area covered and amount of detail wanted. - size assignment in materials*.xml should be done carefuly, with respect to real scale. - on-disk size depends on texture size, amount of colour variation in the texture and compression method. (a 4096x4096px texture can be as big as 10 to 30 MB if compressed as png, or ~20MB if compressed as dxt5 .dds, or ~10MB if compressed as dxt1 .dds, figures for .dds given with embedded mipmaps) -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Lit the lights!
Hello!
Recently i tried to implement cockpit night lightning system in FG and
came around a curious problem i can't solve: definition of
new/additional light sources is ignored by FG. I went the classical
OpenGL path and tried to incorporate additional standard light sources
(OGL supports from 8 to 10 of them depending on the hardware). The code
works so far, BUT only if the light source number is zero. Ergo none of
the lights from 1 to 9 configured with the same code would work. Other
light sources appear to be disabled somewhere in FG/SG, since OSG
demonstrates in the example projects multiple light sources operated.
Altering light 0 also affects the entire scene graph, but that's
expected behavior as noted in OSG docs. Not even rough cut through with
glEnable(...) helps.
Implementation details:
Markup extension:
cockpit_light
source0/source
namecockpit_light/name
colors
ambient
R0.0/RG0.7/GB0.0/BA1.0/A
/ambient
diffuse
R0.0/RG0.0/GB0.0/BA0.0/A
/diffuse
/colors
direction
X0.3/XY0.3/YZ0.3/Z
/direction
offsets
x-m-0.309142/x-m
y-m0.286432/y-m
z-m0.275279/z-m
pitch-deg0/pitch-deg
heading-deg180/heading-deg
roll-deg0/roll-deg
/offsets
spot
cutoff0.002/cutoff
exponent0.002/exponent
/spot
attenuation
constant5.0/constant
linear5.0/linear
quadratic10.0/quadratic
/attenuation
/cockpit_light
Method invocation in:
static osg::Node *
sgLoad3DModel_internal(const SGPath path,
const osgDB::ReaderWriter::Options* options_,
SGPropertyNode *overlay)
...
// process cockpit lights
std::vectorSGPropertyNode_ptr light_nodes;
light_nodes = props-getChildren(cockpit_light);
for(unsigned i = 0; i light_nodes.size(); i++) {
group-addChild(Particles::appendLights(group, light_nodes[i],
prop_root, options.get()));
}
...
Method implemented:
osg::Group * Particles::appendLights(const osg::ref_ptrosg::Group parent,
const SGPropertyNode* configNode,
SGPropertyNode* modelRoot,
const
osgDB::ReaderWriter::Options* options)
{
int lightNum = configNode-getIntValue(source, 0);
// create and configure light source
osg::LightSource *interiorLightSource = new osg::LightSource();
interiorLightSource-setLocalStateSetModes(osg::StateAttribute::ON);
interiorLightSource-getLight()-setDataVariance(Object::DYNAMIC);
interiorLightSource-setLocalStateSetModes(osg::StateAttribute::ON);
// acquire the light itself and do setup
osg::Light *interiorLight = interiorLightSource-getLight();
interiorLight-setLightNum(lightNum);
interiorLight-setPosition(osg::Vec4(configNode-getFloatValue(offsets/x-m,
0.0),
configNode-getFloatValue(offsets/y-m, 0.0),
configNode-getFloatValue(offsets/z-m, 0.0), 1.0f));
interiorLight-setAmbient(osg::Vec4(configNode-getFloatValue(colors/ambient/R,
0.0),
configNode-getFloatValue(colors/ambient/G, 0.0),
configNode-getFloatValue(colors/ambient/B, 0.0),
configNode-getFloatValue(colors/ambient/A, 0.0)));
interiorLight-setDiffuse(osg::Vec4(configNode-getFloatValue(colors/diffuse/R,
0.0),
configNode-getFloatValue(colors/diffuse/G, 0.0),
configNode-getFloatValue(colors/diffuse/B, 0.0),
configNode-getFloatValue(colors/diffuse/A, 0.0)));
interiorLight-setDirection(osg::Vec3(configNode-getFloatValue(direction/X,
0.0),
configNode-getFloatValue(direction/Y, 0.0),
configNode-getFloatValue(direction/Z, 0.0)));
// exponent cutoff
interiorLight-setSpotCutoff(configNode-getFloatValue(spot/cutoff,
0.0));
interiorLight-setSpotExponent(configNode-getFloatValue(spot/exponent,
0.0));
// light attenuation
interiorLight-setConstantAttenuation(configNode-getFloatValue(spot/attenuation,
0.0));
interiorLight-setLinearAttenuation(configNode-getFloatValue(spot/linear,
0.0));
interiorLight-setQuadraticAttenuation(configNode-getFloatValue(spot/quadratic,
0.0));
// state propagations
osg::StateSet *parentState = parent-getOrCreateStateSet();
parentState-setMode(GL_LIGHTING, osg::StateAttribute::ON);
parentState-setMode(GL_LIGHT0 + lightNum, osg::StateAttribute::ON);
interiorLightSource-setStateSetModes(*parentState,
osg::StateAttribute::ON);
return interiorLightSource;
}
P.S. Best result sofar:
http://www.flickr.com/photos/43342833@N04/6344963545/in/photostream
--
All the data continuously generated
[Flightgear-devel] Profiling Results
Hello all, i performed hot spot and thread analysis with current FG code base, here the results: Hot Spots: http://www.flickr.com/photos/43342833@N04/6384920207/in/photostream Threads: http://www.flickr.com/photos/43342833@N04/6384919719/in/photostream -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain textures
Am 22.11.11 20:44, schrieb Adrian Musceac: The problem with small textures is that patterns on them become very visible at high altitudes. On the other hand, good textures with no visible repeating features are quite hard to obtain. Adrian, you might have a look what the crop shader does with a small texture and a colour map (or has done, I am not sure that origin is still in source) and what I took from there to the basic concept of the transition shaders some time ago. At least for me it is a very intersting way dealing with small textures sizes and avoiding visible repeating. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain textures
Am 22.11.11 20:50, schrieb Emilian Huminiuc: - on-disk size depends on texture size, amount of colour variation in the texture and compression method. (a 4096x4096px texture can be as big as 10 to 30 MB if compressed as png, or ~20MB if compressed as dxt5 .dds, or ~10MB if compressed as dxt1 .dds, figures for .dds given with embedded mipmaps) Hi Emilian As far as I can see it is a bit optimistic getting .dds with good quality near 10 MB with 4096 x 4096 size, maps included. What I see recently is that .dds textures mostly gets bigger in the same size than png (same quality), but the shader handling of .dds will produce ways better results and performance ? So probably the size policy is not that important like with png and should be thought new ? Or am I wrong ? Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Profiling Results
Am 22.11.2011 21:13, schrieb Paul Guhl: Hello all, i performed hot spot and thread analysis with current FG code base, here the results: Hot Spots: http://www.flickr.com/photos/43342833@N04/6384920207/in/photostream Threads: http://www.flickr.com/photos/43342833@N04/6384919719/in/photostream You'll need to distinguish between analyzing start-up and run-time performance. The first screen shot mainly shows functions executed during startup. Indeed, the parser functions showing there, like the APT loader and the string utilities, should be an area to look at if you're interested in accelerating the start-up phase. To optimize run-time performance, you'll need to ignore the initial performance data and only evaluate the data recorded after fgfs is fully loaded. cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader properties and dialog
On Mon, 21 Nov 2011 23:04:25 +0100, HB-GRAL wrote in message 4ecacae9.7070...@sablonier.ch: Am 21.11.11 22:08, schrieb Arnt Karlsen: On Mon, 21 Nov 2011 14:55:34 +0100, HB-GRAL wrote in message 4eca5856.6060...@sablonier.ch: Hi Gijs I would be very happy with a reflect checkbox/property once. Just to remember issue #295 (stalled, why?), this one is still broken with my ati on osx, osg trunk. It is not broken at all, but it still produce this renderbin draw errors filling my fgfs log to a huge file running flightgear. I started to avoid aircrafts using this shader, but now I am runnung into the same problems when I start in multiplayer mode with material shaders enabled. ..you have a commandline suggestion I can try to try reproduce this bug? Hi Arnt Starting i.e. b29 and Material Shaders enabled. We can also share the issue in my log, I start with c172p at KSFO 10L and you take the b29 at 10R. ..easy now, I'm on the road with an eeepc that takes about 3-5 seconds of agony between each frame, so dream on on me on multiplayer. ;o) ..the only plane I've done a successful T/O with FG-git on my eeepc, is the ju-52, which _must_ be modeled wrongly, it's a tail dragger that does T/O's straight ahead. Once airborne, the ju-52 is a _lazy_ slow pussycat ;o) ..I _can_ put anything up in the air and do paused screenshots ok. Debian's FG-2.0 does an easily flyable 3-5fps. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Lit the lights!
Hello, It isn't really recommneded to use more than the provided OSG-Lights in FGFS for some reasons. Bur for cockpit lighting we have in 2.4.0 and 2.5.0 ow a lightmap shader, which might be more interesting Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader properties and dialog
On Wed, 23 Nov 2011, Arnt Karlsen wrote: Starting i.e. b29 and Material Shaders enabled. We can also share the issue in my log, I start with c172p at KSFO 10L and you take the b29 at 10R. ..easy now, I'm on the road with an eeepc that takes about 3-5 seconds of agony between each frame, so dream on on me on multiplayer. ;o) Talk about an excercise in total futility. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
Spoke too soon. The trees look great, but the frame rate hit makes it unusable (from 30-35 to 2-4) even with the other shaders disabled. Thank you! I haven't had seen trees in FlightGear for ages (can't run with shaders). I didn't realize the trees were supported at all without shaders. Trees are still done with shaders - all that is being discussed is if the menu option 'material shaders' should deactivate trees as well, or if it is sufficient to just (de)-activate trees using their own checkbox. * Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain textures
On Tue, 2011-11-22 at 21:44 +0200, Adrian Musceac wrote: The problem with small textures is that patterns on them become very visible at high altitudes. On the other hand, good textures with no visible repeating features are quite hard to obtain. I've tested on my setup with up to 4096x4096, mapped on a correspondingly high area. This gives very good results at high or low altitudes and almost eliminates the need for more than one texture per material, but the size of the textures becomes a problem. Anyway, I think it would be a good idea to keep the high detail textures for the future, or as an option for those who can afford it now, and scale them appropriately for default usage. What I meant was to lower the pixel-resolution to a point where it starts to make a difference, not to lower the cover area of the texture. Erik -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
