On Tue, Apr 19, 2011 at 9:13 AM, Geoff McLane <ubu...@geoffair.info> wrote:
>
> Quite some time ago now ran into this NULL ptr
> passed to the merge_left() (internal) gpc library
> function, when trying to process dense (very detailed)
> data, but even after adding code 'protecting' against
> such a segfault, the resultant tile produced could
> not be displayed correctly by FG rendering engine.
>
> See the tile results here -
> http://geoffair.org/tmp/2892641.htm
>
> There were 2 types of 'bad' tiles, named by Cullam and I
> as (a) 'painters' Mondrian style, with parallel banding,
> and (b) 'spaghetti', where triangles cross each other
> in multiple layers...
>
> We suspected somewhere a 'short' is used instead of an
> 'int' counter, since it always seemed to happen when
> some component counts exceeded 65536 ;=(( But could NOT
> track it down... and anyway maybe this does not address
> the gpc library problem...
>
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. So if the number of items exceeds 32767,
then you will get indexing errors and all kinds of weirdness in the result.
I think the code (at least as it appears now) has been updated to use
unsigned int counters so this boosts us up to 65535, but beyond that you
will have these sorts of problems.
However, Since there are now many scenery builders wanting
> to use the higher resolution data available, a fix at both
> levels, gpc polygon massaging, and fg rendering, would be
> VERY MUCH appreciated.
>
> Anything I can do to help...
>
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.
The btg file format is versioned, so we could create a new version number
and add code to handle the new format variant.
Also when you push this many polygons through the render pipeline, know that
you are going to grind a lot of people's machines to a halt. That's not
necessarily a reason not to push more detail, just something to be aware of
... hardware is always getting faster of course.
Any updates here would require compatible change between the terragear tool
chain and the simgear btg loader.
Regards,
Curt.
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
------------------------------------------------------------------------------
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
