Hello Johannes,
On 12/09/2010 02:30 AM, Johannes Brunen wrote:
> did you have time to look into the code?
a little bit, looks good to me.
>>> 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...
hm, Dirk, Gerrit any opinions on this?
>>> 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?
you can register higher priority loaders at any time, but there is not a
good way to go back and forth between them. Is that needed?
>>> 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?
as I said, not terribly important.
>>> 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.
here is a vertex shader I use to perform vertex skinning animation on
the GPU. A vertex has a position, a normal, four joint indices (stored
in gl_MultiTexCoord2), and four joint weights (stored in gl_MultiTexCoord3).
// forward decl
void calcSkin(inout vec4 pos, inout vec3 norm,\n"
in vec4 matIdx, in vec4 weight);\n"
varying vec4 position;
varying vec3 normal;
void main(void)
{\n"
vec4 pos = gl_Vertex;
vec3 norm = gl_Normal;
vec4 matIdx = gl_MultiTexCoord2;
vec4 weight = gl_MultiTexCoord3;
calcSkin(pos, norm, matIdx, weight);
gl_Position = gl_ModelViewProjectionMatrix * pos;
position = gl_Position;
normal = gl_NormalMatrix * norm;
}
On the OpenSG side there are four GeoProperties on the Geometry:
geo->setProperty(pos, Geometry::PositionsIndex);
geo->setProperty(normals, Geometry::NormalsIndex);
geo->setProperty(jointIdx, Geometry::TexCoords2Index);
geo->setProperty(jointWeight, Geometry::TexCoords3Index);
I'm not sure if this is enough to explain it, please ask if you need
more details.
>>> 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.
no, you can access all the lights properties (position, color, etc.)
through the gl_LightSource[i] built in uniform, but the piece of
information that is crucially missing is if the light is actually
enabled (i.e. if glEnable(GL_LIGHTi) was called).
> Why should I not be able to setup the shader to respect for instance all
> defined
> lights with their specific types?
determining the type of light source requires examining the light's
properties (e.g. if gl_LightSource[i].position[3] == 0 it is a
directional light), it can be done, but slows the thing down, especially
since it needs to be done in the fragment shader.
>> 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.
hm, your bump map shader does not evaluate TEXTURE1_MAP or TEXTURE2_MAP
to determine basecolor, it just uses a fixed value. Just for the three
textures (TEXTURE1_MAP, TEXTURE2_MAP, BUMP_MAP) you need shaders for:
no texture (maybe not needed)
only tex1
only tex2 (maybe not needed)
tex1, tex2
tex1, bump
tex2, bump (maybe not needed)
tex1, tex2, bump
so even optimistically there are 4 combinations to deal with and that is
only for three input textures, that's what I meant with combinatorial
explosion.
Cheers,
Carsten
|