Multi-texturing/Multiple Textures

Engines, Libraries and Tools Java 3D
#1

Having a lot of problems with both kinds of multi-texturing. First, the ability to place different textures on differing faces of an object. Second, the ability to place more than one texture on a given face. Then of course there is doing both at the same time.
The only way I seem to be able to do this is to split up my geometry and build a separate shape3D for each part with an appearance which hold only those TextureUnitStates that are used in that sub-geometry. This leads to a lot of Shape3D objects.
I tried doing the first type by stacking the verts, normals and texcoords into one geometry array and using the initial vert index (in the texcoord adding method) to point to the starting vert effected. Then mapping the texcoord sets to TextureUnitStates in the Appearance object holding all the textures for the Shape3D. This resulted in the highest indexed TUS texture being shown on all faces of the shape.
Alternately, I tried doing a combination by creating one Appearance with all the textures and placing the sub-geometries in their own geometry arrays, which were added to the Shape3D. The texcoordset to TUS map for a one of these Geometry array would typically look like this:


Index      Value
0      -1
1      -1
2      0
3      -1
4      -1
5      1

In this case too the highest indexed TUS texture seemed to predominate. The docs say that using -1 prevents that TUS from being used in that geometry array. The map above should be equivalent to using an Appearance with 2 TUS and a map of {0,1}. Of course this requires more Shape3Ds.
However, that does not seem to be the case. If an Appearance object includes TUS not used in a particular sub-geometry then there seems to be some bleed-over. The highest indexed TUS always predominate.
Is there a capability bit I’m missing, a Texture/Rendering/etc attribute I’m missing? I’m using DECAL for the base texture and COMBINE_ADD for the second which is a lightmap.

#2

You need to break up the geometry. If a part of the geometry needs it’s own appearance, it needs it be broken up.

Don’t understand what your goining on about indexing etc, so I can’t comment. Your probably trying to solving the problem by making it incredibly complex.

#3

I’ve always been able to do it by breaking up the geometry and creating a Shape3D for each sub-unit but that makes for a lot of Shape3Ds (5-9/shape for simple buildings). When you consider that a Shape3D can have more than one geometry and the texcoordSetMap in each one should be able to select only those textures used in it, it should work. Also each GeometryArray can have many sets of verts, normals and texture coords; with the texCoordSetMap selecting the TUS(s) for each TCSet.
Surely all this functionality is not there so you can gather all the “Blue Trim” e.g. geometry in one Shape3D. That is useless and counter productive to things like animation. Read the docs and tutorials on the texCoordSetMap in GeometryArrays and how it’s supposed to work. That’s the indexing I’m talking about.

#4

I’m afraid you have misunderstood the docs. When there is a -1 in the texCoordSetMap it means that it will not use any texture coordinates that you provide on that texture unit. But that “layer” is still rendered. It can use texture generating instead. If that is not on I don’t know what it use. It is possible it just inserts (0, 0) as texCoords on all vertices.

In the example in your first post you specify what texture coordinate set that will be used for each of the texture units. Again, all the texture units WILL BE USED. Also, the card must support 6 texture units. Many cards only supports 2 or 4 texture units. In wich case your code won’t even run.

The ONLY way is to break up the geometry. To reduce the number of Shape3D objecst you can merge geometry that has the same Appearance, if they are close to eachother and don’t move relative to eachother. Short of that you just have to accept that there will be alot of Shape3D objects. Thats just how it works.

#5

Thanks for the reply. It’s kind of disappointing. Considering that one of the things I’ve seen that helps with speed is limit the # Shape3Ds. So it may work the way I expect it to some time in the future when video cards can handle that many textures. But now no way.
I was getting a lot of slowdown with terrain and a dozen buldings. Have to get out a ways before fog, etc has a chance of being realistic. Explore all the other ways of cutting overhead.
It does explain the phenomena of the higher indexed texture predominating(FIFO). Guess it’s a pitfall of using a high level of abstraction, that you can fall into the trap of forgetting about the hardware.
Thanks
Jim