Results 1 to 4 of 4

Thread: Texcoords generation/reflections

  1. #1
    Junior Member
    Join Date
    Jun 2005

    Texcoords generation/reflections

    Having browsed through collada specs, i could not find anything about reflections (spherical, cube), or, in more general case, texture coords generation. There is something said in specs about texture mapping information methods (planar, spherical etc), but it does not look like the solution (at least until it is documented in common profile. or maybe i missed something?)

    Are there any plans or ideas of designing this feature?
    Thank you.
    Roman A.

  2. #2
    Senior Member
    Join Date
    Aug 2004
    The 1.3 common profile includes texcoord (STPR) texture mapping as you noted. You can define your own <technique> to describe reflection maps (as has been done for an E3 demo) or other shader based approaches.

    Our plans for COLLADA 1.4 includes high level effects (COLLADA FX) that supports features similar to other formats like CgFX and FX. We plan to support effects descriptions for Cg, HLSL, and GLSL. As part of this new design comes general improvements and changes to existng COLLADA material, texture, and camera elements.

    With an emphasis on effects and shader approaches, we have not decided to introduce symbols into the common profile for texture mapping (e.g. <program> id and url attributes). We can do this if there is demand for it. Post a list of the mappings you want to be common.

  3. #3
    Junior Member
    Join Date
    Aug 2004
    SCEA, Foster City
    The idea behind COLLADA FX is to provide cross-platform descriptions of fixed-function or programmable pipeline effects using single or multiple passes in a platform-agnostic manner. Say you wanted an reflective environment map effect that works on HLSL, Cg and GLSL versions of a model, COLLADA FX would be able to describe each shader (and multiple versions of each shader for, say, low and high LOD implementations) in the same document.

    For example, a Cg implementation of an environment map might look like this:

    Code :
    <effect id="reflectionmap">
      <technique name="single_pass">
                // some Cg source code here
                uniform samplerCUBE myCubeMap;
                float4 vertex_shader(uniform float4 cameraPos : CAMERAPOS,
                                     uniform float4x4 ModelViewMatrix : MODELVIEWMATRIX,
                                     out float3 tex : TEXCOORD0,
                { ... }
                float4 fragment_shader(in float3 tex : TEXCOORD0
                                       uniform samplerCUBE cubemap;
                { ... }
            <setparam ref="myCubeMap">
                <shader stage="VERTEXPROGRAM">
                <shader stage="FRAGMENTPROGRAM">
                    <bind symbol="cubemap">
                       <param ref="myCubeMap"/>
    This <effect> can then be used to define a <material> to be used on your models. Easy as that!

    - Robin Green
    Chair of the COLLADA FX Working Group

  4. #4
    Junior Member
    Join Date
    Jun 2005
    Shader approach is ok in general and can be used to describe any special effect such as reflection ofcourse.

    But imagine the very common situation:
    3d modeller designs some object; one of the materials uses spherical reflection (modeller just checks "reflection map" checkbox in modelling package and chooses a texture to be used for mapping). Modeller doesn't know anything about shaders and vertex programs, he just wants reflection and he is right.

    What happens next? Collada exporter tool (e.g. one of the tools provided here) should be customized to process reflection map case and generate proper Cg code. Every change of engine rendering pipeline will require update of the exporter tool - right, we change the method things render, so Cg code changes too. This increases overall asset pipeline complexity and may result in decreased effeciency - someone will always use old exporter version.

    There is one more problem with shaders - they have to be stored somewhere. Having one object with simple spherical mapping code inside is cheap, but thounsands of objects in memory produce thousands of similar shader copies. Ofcourse this problem can be solved by preprocessing data, changing shader copies to references or caching shaders in runtime - but it costs some additional time.

    I think the general idea should be something like "simple things should be simple, advanced things may be complicated".

    Ah, mappings
    I think mappings list should include "screen-space planar", "object-space planar", "spherical" and "cube" mappings. That should be enough for most common cases.
    Roman A.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts