Hi Patrick, hi Gerrit,
Patrick Dähne wrote:
>
> Yes! Consider the case when you want to use the same texture twice,
> but with different envmodes. When the envmode is part of the Obj
> chunk, you have to copy the same texture twice into the texture
> memory. When the envmode is part of the Env chunk, you can share the
> texture object. It's just a matter of efficiency. I strongly object
> to putting any status variables into the Obj chunk that are not part
> of the underlying OpenGL texture object.
In theory I can see that, but how often has that happened to anybody?
There are not many cases that I can think of where you need the same texture
with different env modes. On the flipside it makes using textures more
complicated than it is already, so I'd prefer making things simpler, if
possible.
Gerrit Voss wrote:
>
> further on the background of the split (as I did it ;-)) :
>
> actually it was mainly not because of the size but because I wanted to
> use TextureObjRefChunks, still be able to control the environment and
> avoid code duplication.
>
> So a little bit I would prefer to keep it separated (but I see the
> complicated part of it). We could move it back to TexObj and add
> something like a FullEnv chunk which can override the TexObj settings.
> Adding another chunk might be overkill.
>
> Another option would be to add it to either TexObjRef (too) or TexBase
> that looks kind of strange, but a workable solution.
>
> Or we keep it inside both (worst case IMHO) but this might be to
> confusing (even if the winning rules are clear). Especially for
> tools.
Of those adding it to the RefChunk, too seems to make the most sense to me,
personally.
Comments?
Dirk
-------------------------------------------------------------------------
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.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
