On Tue, 2011-04-19 at 09:29 -0500, Curtis Olson wrote: [] > Yup, this is definitely a problem. In order to keep file sizes down, > the index into the vertex, normal, and texture coordinate lists is a > "short" ... it might even be a "signed" short. [] > Tradeoffs ... if we switch from short to int, we double the size of > the section of the btg file that indexes back into all the vertex, > normal, and texture coordinate arrays. With the world scenery already > pushing 12Gb, this is a significant decision. Also we need to protect > some backwards compatibility. >
Hi Curt, I agree the 'public' world data size should not grow much beyond the current 12Gb, and we MUST maintain some backward compatibility, and that is why perhaps your BTG format presently starts with a (word) 'SG' signature ;=)) and a (word) version 6... There is no double people WANT to be able to generate scenery for the specific area they know and LOVE. It probably breaks their heart each time they fly over it and say to them selves where is that important turn in the river?, the little bay?, that small hill? (like the recent Rio comments), etc, etc, etc... So such a unsigned int BTG 'signature' certainly opens the way to have other 'versions' of the BTG file, as you suggest, and then users can be _WARNED_ it can only be generated by TG 2.3?, and loaded/viewed by SG/FG 2.3 plus... And they can further be warned that such a 'new' BTG file may indeed require 'better' hardware... raising the min. requirement... but machine power is forever increasing anyway... as you mention... Hmmm, while I thought I had researched EVERY counter, as you point out, in all cases I observed that is now an int, which gives us +/-2,147,483,647, which should be ok, but sort of forgot to look very closely at the index lists themselves ;=(( If these are shorts, or even unsigned shorts, then that is BIG trouble for high definition scenery... which can easily go beyond 65K indexes per tile... you can even do it now with modest raw data, but push terrafit to break up the DEM into a smaller elevation mesh... So are their others interested in going forward with a 'new' BTG? Let us hear from you... Who can help, do what? I know and read some, like Martin, want to go perhaps another direction, and that too is fine... but in the interim why not just 'extend' what we have? Regards, Geoff. PS: I remember someone, off list I think, mentioning that maybe the gpc library has been improved... must try to re-find that reference... there is also no doubt polygon clipping is integral to a new BTG format... ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
