We are using LightMapMethod for some Materials, but have some Problems with that.
We are loading two meshes. One with uv data for the diffusemap and another mesh with the uv dataset for the lightmap.
After updating the secondary UVData (updateSecondaryUVData) we get an error:

RangeError: Error #3669 - uvbuffer

the meshes with uv data seems to be correct. Checking this already with Prefab. Do you have an idea whats wrong?

using the same uv’s for both the first and second uv dataset works. But using another uv’s for secondaryUV Data don’t work.

In Prefab you have same uv/vertex count and it’s same mesh?
You do not weld or something on one of them that would affect the amount of uv’s or indices?
If you trace subgeom uvdata and indexdata length, are they are of same length?

it’s the same mesh but the mesh for the lightmap has diffrent uv’s. and not the same length. because of the tiling uv data from diffuse map that wont work with the lightmap, that need to use non tiling uv’s.

Here you go then: uvs values may of course be different, but the uv buffer.length of the primary and secondary must be same.

I do not see why the tiling would affect at all, in fact what you want is pretty much the main use of this class. An example is for instance to make a plane, say a wall, prebake the light info on it, so mapped 0-1, and have a “brick” map that you tile/repeat. at runtime you have nice bricks if you go near of wall, while having the scenery lighting on entire wall, not being tiled.

here just to illustrate
http://www.closier.nl/playground/lightmap/LightMapTest.html

Hello,
my name is Damir. I work as a 3d Artist together with Ole now.
I try to explain why utilizing the same UV Buffer lenght means a disadvantage for us.
First of all here is an Example Asset from out Project. Its a Building
You can see the diffuse Texture and the diffuse UV Layout underneath.
http://www.simovski.com/gw/Assettower.jpg
As you see we utilize Tiling on the texture through overlapping segments:
http://www.simovski.com/gw/DiffuseTiling.gif
Now there are 2 Methods to Unwrap this element for Lightmapping:
Packing the same Shells (connected UV data) right next to each other or as one Piece.
Have a look here:
http://www.simovski.com/gw/Lightmap2ways.jpg
The “One Piece” Method gives us 2 advantages:
Less wasting of UV Space as it is easier to integrate into packing.
Less splitting of UV Data as there are less boundary uv points. Easy to read from the statistics to right of each method (picture above).

In case of a lot of buildings the amount of UV data “wasted” gets important for us in Terms of
Performance (more transformed/processed data)
file size (as there are bigger)

Additionally we currently cant perform an optimization on UV data like merging or welding points what gives us the bigger file size.
If we do that on the diffuse UV data, which would make sense as there are a lot of overlapping UV points, we would change the UV Buffer lenght. But then we cant pack the shelss side by side as this would mean a different uv buffer.

I hope my eplanation wasn t too confusing
yours
Damir

I understand your issue but, how would the program know how to use them? So lets say it would be possible, you would need an extra index buffer. But here comes the problem, each and every vertice requires a uv coordinate. and if its not same length… it simply doesn’t work.

Most simple and efficient way would be to organize your maps per type of materials and store the repeats values. Once loaded you apply these uvtransforms. No need to store entire sets of uv’s.
So the art is to uvmap your model in a way that fits your repeats, yet keeps every face area unique on the map to allow prebaking too.

Hello Fabrice,

thank you for the quick answer.
I can t tell you how the other engines - i m used to - do this kind of stuff as i m not a programmer.
As there is currently no other way than using the same UV Buffer lenght - We will adapt to that

happy staging

Hello again

we just tried to give the New 4.1 Alpha a shot and stumbled across a Problem with secondary uv sets
It seems that there is no “updateSecondaryUVData” commadn anymore, which we used to fill in the Secondary UV data.
I guess there is a new workflow (?) but we didnt find any Documentation.
Is it now possible to use different UV Buffer lenght?
Also there seems to be the need for a named StageProxy ...

What is the Workflow for utilizing those Secondary UVset data ?

yours
Damir