-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christian Mayer wrote:
> Josh Babcock schrieb:
>> LeeE wrote:
>>> On Sunday 30 December 2007 09:47, Detlef Faber wrote:
>>>> Hello,
>>> Could it be that the overhead of rotating many simple billboard 
>>> objects accounts for the performance hit over an equivalent number 
>>> of more complex static models?
That does have significant overhead as it is all done on the CPU
>> Probably has more to do with the fact that the billboards are not only 
>> UV mapped, but also have an alpha channel. These new ones appear to just 
>> be using OGL materials. I wonder, does OSG do vertex painting? That 
>> would be a great way to make these look better without adding a texture.
There should be no problem with using textures for the trees on any hardware
manufactured after the early part of this century. In the OSG world we will 
have to
take some care that the trees are not depth-sorted as that will be quite 
expensive with
high tree densities.
> 
> I'm a bit out of the current 3D programming that FGFS uses... But
> wouldn't a vertex shader help in this case (for billboarding as well as
> generic trees)?
> 
They would help with a lot of things with respect to trees:
* you could do the billboarding in a shader, as you mention;
* there's a trick in OpenGL that is demonstrated in the OSG osgforest demo that 
uses a
shader to create very cheap tree "instances" that don't incur the cost of matrix
transform for each tree;
* everything else you can do with shaders to make things look good.

I would think that we would punt the billboarding if we can come up with a 
cheap 3D tree
that is convincing from the air.

I changed the subject because we currently have no way to specify shaders other 
than
to hard-code them in the C++ code. In general, the parameters we specify for 
materials
are quite limited. I've been studying the Ogre (www.ogre3d.org) materials 
system for
a while and think that the syntax of their material scripts system, 
www.ogre3d.org/docs/manual/ ,
adapted to XML property lists and FlightGear needs, would be quite excellent.
It seems quite exotic from a FlightGear point of view, but we will soon have 
shadows
and multi-pass lighting (for landing lights) and we will need some way for 
materials
to interact with them.
> CU,
> Christian

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHd+WseDhWHdXrDRURAph/AJ9HYi/XH8qGgkh2YHxaqkp+VubargCfRKVH
inj9a/+CT3y06ItiwGH8Nwk=
=nM2j
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to