Hi Manfred,
On Tue, 2005-02-22 at 10:51, Manfred Weiler wrote:
>
> You know the actual reason was, that the user should never bother about
> texture management. We had this discussion before that this parameter
> is acutally system dependent and I therefore didn't want to expose it
> in the first place.
Yeah, in a perfect world that would be the solution. But thinking about
it, the user might still want to have some control over how much memeory
is given to the volumes compared to other thingsa in hte scene, so I
don't feel too bad to give up some control.
> It just served as a placeholder for functionality
> still to be provided by OpenSG ;-)
We're working on a tool to get that info (aegisknight.org/glscry) that
will then be fed into OpenSG. But even given that I think some control
would make sense.
> However, it seems that there is currently no good solution in sight.
> So maybe exposing this parameter could serve as an "intermediate"
> solution. But what would be a good default value? If it is too large,
> the volume node will not run on older systems. If it is too small
> lots of people on newer graphics boards will run into performance
> issues.
Seeing that the currently used crop of cards has at least 64 M of
texture memory (Octanes and Indigos don't count any more ;) I'd say 16 M
is a safe bet.
> Could we somehow achieve a graceful behaviour, so that not just
> a crash or some OpenGL error in OSGImage indicates, that the brick
> size was too large?
>
> Should "-1" indicate, that the volume node should try to determine
> the size for itself?
>
> Should Image provide some static method to determine whether a
> texture of particular size could be created (using OpenGL texture
> proxy or just a teximage call with NULL as data argument --- is
> any of this mechanisms working reliable on more than one platform).
> If the Image or some other OpenSG object would perform this test
> than it could also cache result to greatly improve performance.
I would hope that the proxy mechanism is realiable, that why it was
added in the first place. Currently OpenSG doesn't expose it, though.
> You see, there are a lot of issues involved here. That is basically
> why I refrained from committing to expose brick size handling.
Yeah, it's a hairy topic, no doubt about it.
> So decide which is the less painful solution, I am comfortable with
> any/neither of them.
The least invasive solution would be to just make the field public.
Given that is also the minimal work solution that's what I would propose
for now. ;)
If there are no objections I'll change the default to 16 and check it
in.
Dirk
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
