Hi Allen,
Allen Bierbaum wrote:
>>> * COLLADA plugin support for both the reading and writing of COLLADA
>>> 1.4 .dae files.
>>>
>> That's a nice one, admitted.
>>
> So can we build off of it?
>
From what Gerrit wrote it looks like they're pretty comparable anyway.
>> That's a trivial thing to add to the Thread abstraction. AFAIK from the
>> source they don't do anything automatic, you have to tell the system
>> which processor you want to run each thread on.
>>
> If it is trivial, can we get it in for OpenSG 1.8. It may be trivial,
> but it can also be critical in some cases.
>
If anybody wants to do it, be my guest, I'm a little swamped right now.
If you do it, please also do it for 2. ;)
>> That's not a bad one, but the implementation is the simplest possible
>> way and not very efficient in terms of texture memory use (simple linear
>> greedy fitting). It will probably still give a speed boost for many
>> cases, but there's not a lot to it. They seemed to have taken good care
>> of all the corner cases though, which is one of the main problems for
>> these kinds of things.
>>
> So if it has a simple implementation could we port it over to OpenSG
> fairly easily?
>
The main problem is changing the texture matrices/coordinates on the
changed objects. If we're willing to make this non-totally-general it
should be fairly easy.
> Anyone interested in doing this????
>
I'd be happy to give hints if anybody wants to give it try.
>>> * GPU timing stats have been added to the viewer class, provided the
>>> time taken to process allow drawing operations down on the GPU for
>>> the previous frame. Coupled with the existing timing of CPU
>>> update, cull and draw dispatch the stats reporting now provides
>>> the end user with a clearer idea of whether their application is
>>> CPU or GPU limited and server as a better guide to performance
>>> optimization work
>>>
> I would be intersted in working with you on this for OpenSG 2.0. I would
> really like to get some of these stats.
>
Jan Springer and his people have added this for 1.6, but I haven't
looked at it yet. If somebody wants to give it a try please let him
know. I assume Gerrit is thinking about it for 2 right now. It's coming.
>> OSG has an advantage with their local state overrides there, so that
>> will be harder in OpenSG. I've been interested in Texture Atlass before,
>> but more for normal map generation, which is a much harder problem and
>> one that I javen't found a nice solution for. Note that both NVidia and
>> ATI have free tools for creating those, so if you need them take a look
>> at those.
>>
> Approximately how much effort would this take? Is it a weekend project
> or a master's thesis?
>
It's more about how general do we want to make it. If we restrict
ourselves to changing texture coordinates instead of matrices it would
be a busy weekend but a weekend nonetheless.
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
