Re: [Flightgear-devel] VC90 compile fail in WaypointList.cxx
Hi Frederic, Yes, I am afraid. This code construction show up in the code from time to time and we have to provide a replacement. I think the best approach is to use an auto_ptr. std::auto_ptrchar buf( new char[len] ); in order to be exception safe. For array allocations, you need to take care that the array is deallocated using the array delete [] operator, i.e. char *buf = new char[len]; delete [] buf; Using an auto_ptrchar is incorrect in this situation, because it will deallocate using the non-array delete operator. You should use boost::scoped_array (or boost::shared_array if it is to be reference counted) instead. Regards, Manuel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VC90 compile fail in WaypointList.cxx
The last time I went down this path, I ended up back at good ole std::vector. In this context, std::string would be just fine too. second that :-) Manuel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VC90 compile fail in WaypointList.cxx
Hi Fred, In theroy, you are correct, but as long as char doesn't have a destructor, this is totally overkill, and not very efficient. If the type has no destructor, it won't be called, so the efficiency argument is moot. But the real issue is that calling delete on an array has undefined behaviour. While it often works in practice (because often delete [] defers to delete), it can cause heap corruption (depending on the runtime library or if the delete implementations have been overridden). Additionally, you'll make valgrind puke :-) (and rightly so) See http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.13 cheers, Manuel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch ( fu rther invesigations )
Hi Roman, I played with 3D clouds patch in my sandbox and forgive me if I'm not familiar with whole flightgear/simgear system. Now I try modify existing code of 3Dclouds to pointsprite usage. Roman I am not sure point sprites are a good solution here... Altough they're put to good use in small-scale particle systems with high vertex counts (e.g. something like Mark Harris' cloud rendering), they're probably not so well suited for this implementation (based on Niniane Wangs' Paper, AFAICT), where clouds are modeled at a somewhat coarser scale. For example, point sprites are clipped like points (at least according to spec), so billboards will pop into/out of view as the center vertex crosses the viewport. Perspective-correct point size scaling is possible by fiddling with the point size attenuation, but still the billboards are constrained to be square and to be aligned with the imaging plane, so we would loose some flexibility in modelling the clouds. I think the current system would be better optimized by using impostors, because performance is probably impacted more by pixel throughput than by geometry (which btw might perform better by using arrays instead of single quad draw calls in CloudShaderGeometry.cxx). Would be interested in your benchmarks anyway - what I said being mostly theoretical :-) Manuel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
Hi Stuart,
Attached is a small fix for the sorting in CloudShaderGeometry.cxx.
I think the sorting problem stems from the osg idiosyncracy
to store transposed matrices...so the intuitive
osg::Vec4f p = vm * osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f);
needs to be replaced with...
osg::Vec4f p = vm.preMult(osg::Vec4f(_cloudsprites[i]-position.osg(),
1.0f);
The patch also optimizes the distance calculation - it evaluates the distances
in model space instead of eye space, which reduces computation to a dot-
product instead of a matrix multiplication.
bye,
Manuel
Index: CloudShaderGeometry.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/sky/CloudShaderGeometry.cxx,v
retrieving revision 1.2
diff -u -r1.2 CloudShaderGeometry.cxx
--- CloudShaderGeometry.cxx 6 Nov 2008 21:58:07 - 1.2
+++ CloudShaderGeometry.cxx 9 Nov 2008 03:34:23 -
@@ -34,27 +34,32 @@
{
void CloudShaderGeometry::drawImplementation(RenderInfo renderInfo) const
{
+if (!_cloudsprites.size()) return;
+
osg::State state = *renderInfo.getState();
osg::Matrix vm = state.getModelViewMatrix();
//TODO: It isn't clear whether this is worth the perf hit ATM.
-// Do a single iteration of a bubble sort. We do this in reverse
-// so that elements closest to the camera bubble to the front than
-// the elements further away
-for(int i = (_cloudsprites.size() -2); i = 0; i--)
+// Transform the viewing direction, represented by the eye space vector (0,0,-1, 0), into model-space
+// (here we simply take the opposite direction and reverse the ordering when sorting)
+osg::Vec3f view_dir(vm(0, 2), vm(1, 2), vm(2, 2)); // Caveat: OpenSceneGraph matrices are transposed!
+
+float p = view_dir*_cloudsprites[0]-position.osg();
+// Do a single iteration of a bubble sort, sorting
+// back to front.
+for(int i = 0; i _cloudsprites.size() - 1; i++)
{
-osg::Vec4f p = vm * osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f);
-osg::Vec4f q = vm * osg::Vec4f(_cloudsprites[i+1]-position.osg(), 1.0f);
-
-if (p.z() q.z())
-{
+float q = view_dir*_cloudsprites[i+1]-position.osg();
+if (p q) {
CloudSprite c = *_cloudsprites[i];
*_cloudsprites[i] = *_cloudsprites[i+1];
*_cloudsprites[i+1] = c;
}
+else
+p = q;
}
-
+
const Extensions* extensions = getExtensions(state.getContextID(),true);
for(CloudSpriteList::const_iterator t = _cloudsprites.begin(); t != _cloudsprites.end(); ++t)
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Hi Durk,
Firstly, yesterday I managed to speed-up the replay system, by using
dynamic allocation instead of pushing copies of rather large objects into
the STL lists. Using the timestamping code I mentioned yesterday, and
committed to CVS earler today, I found that memory allocation was very slow
on my machine. By preallocating a significant number of replay objects, and
recycling used ones instead of reallocating them I managed to get minimize
the amount of replay timing errors considerably.
Concerning the replay subsystem, I also found what appears to be a c'n'p error
in FGReplay::init(), which results in the long term queue not being cleared.
Probably not significant in this case, though...
Index: replay.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Aircraft/replay.cxx,v
retrieving revision 1.5
diff -u -r1.5 replay.cxx
--- replay.cxx 21 Mar 2006 18:52:19 - 1.5
+++ replay.cxx 30 Sep 2007 16:30:50 -
@@ -76,8 +76,8 @@
while ( !medium_term.empty() ) {
medium_term.pop_front();
}
-while ( !medium_term.empty() ) {
-medium_term.pop_front();
+while ( !long_term.empty() ) {
+long_term.pop_front();
}
}
bye,
Manuel
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] compilation pb: error: 'const class osg::Viewport' has no member named 'getViewport'
Sébastien, I posted a compilation fix yesterday, see http://sourceforge.net/mailarchive/message.php?msg_id=37837809 bye, Manuel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
