Hello Carsten, did you have time to look into the code?
>> Johannes Brunen wrote: > Carsten Neumann wrote: > > hm, if lib3ds needs to be modified, having it as a separate shared lib > does not have much benefit, perhaps just compiling the modified code > into the new loader is the most convenient way to go then? > No, I think the best option is to give the library a unique name. I do not expect conflicts with the original lib3ds dll. Actually, the changes are really minor. However, I'm open minded at this end... >> b) Changes in OpenSG to access this new suppport library. I'm not sure >> about >> the correctness of this part, however. >> >> c) Little modifications to SceneFileHandler. This is necessary, as the >> current implementation does allows to install multiple file type handlers >> for the same suffix, but it does not provide any means(?) to actually use >> another one than the first one in the mapping list. I did some shortcut >> in >> allowing to subtract scene file type handlers the user is not interested >> in. >> I did provide an example 'lib3dsloading.cpp' for that. I think that we >> should provide some means for the user to write its own file type >> handlers >> for already handled file types. Maybe he has an in house handler for the >> same file type or he must handle files of a different type but using the >> same suffix. > > when registering a handler for a file type you can specify that it can > override existing handlers and what priority it has when overriding (see > 3rd and 4th argument to SceneFileType c'tor). > I did try that and it worked. But does this interface allow to change the type of loader at runtime? >> d) A scene file type handler for 3ds which uses the lib3ds library as its >> backend. I have named it 'A3DSLibSceneFileType' and you can found it in >> 'opensg\Source\System\FileIO\3DSLib'. I would appreciate if this could be >> part of OpenSG. Maybe it could be placeed in the contrib section. >> However, >> the handler works already pretty fine (but could be finer, see below for >> that). > > ok, but why not Lib3DSSceneFileType? I always found the leading 'A' to > make it a legal identifier in C++ not very appealing - not terribly > important though ;) > Probably the 'A' comes from 'Autodesk'. I did not want to change the 'naming policy'. Therefore I stuck to it. Should I change it? >> >> I do not know about the semanic of some of them but would like to provide >> support for the as much as I can. > > I don't know what they are used for exactly either and some of it sounds > like it would be quite tricky when not using an offline raytracer... > So lets concentrate on the simple ones. E.g. the Bump Map texture >> >> So my first question goes as follows: >> How do I implement this case in OpenSG? > > for the time being you'll have to use gl_MultiTexCoordN to access vertex > attributes. > Oh, sorry, but I do need more information at this front. Could you explain the technique a little more in the context of OpenSG shaders? A simple example would really be nice. >> As you can see in the implementation file >> 'opensg\Source\System\FileIO\3DSLib\OSG3DSLibLoader.cpp', I have already >> set >> up a simple shader in function 'handle_bump_map'. >> Could you provide me with some details about how to setup the case of >> attribute variables? >> I did read the archive but could not make much sense about what I found >> there, sorry. > > >> Additionally, do you have knowlege about how these should be handled in >> OpenSG? > > well, the problem is that some (all?) of them will require shaders to > actually work and unfortunately that means it is almost not possible to > support this in a fully generic way - as an example of the kind of > problems that come up: How many lights should be considered in the > fragment shader and what type of light source do they represent? I thought that I would have full GL state infromation inside of a shader program. Why should I not be able to setup the shader to respect for instance all defined lights with their specific types? > How do you fight the combinatorial explosion of all the combinations of > different textures that can be present/absent? I do not understand that correctly. If you look at the code you will see the general scheme I had in mind. Might be not the right way to solve the problem, so. > I'm afraid I don't have answers to these questions, but I'd be curious > to hear about ideas for/experiences in solving these. > As I'am... Best, Johannes ------------------------------------------------------------------------------ This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
