hi

i played arround with the “weld.as” and noticed several things:

- its very very slow, and gets slower and slower with the size of the mesh…

- it does not take the mesh down to the lowest possible bufferlength
  (after applying weld a cube with no subdivisions should exists out of only 8
  verticles, but the function gives back a mesh with 10 verticles.
  cube with 10 subdivisions on each axis should have 602 Verticles, function
  gives back 605)
 
- it destroys existing uv-maps.
- it allways sets “autoDeriveVertexNormals” to true.

i made a class “WeldOptimized.as” that calculates the meshes correctly and even much faster.

welding a Cube with Subdivisions 10 x 10 x 10:
Weld.as takes 582ms and gives back 605 verticles
WeldOptimized.as takes 19ms and gives back 602 verticles

welding a Cube with Subdivisions 20 x 20 x 20:
Weld.as takes 8117ms and gives back 2405 verticles
WeldOptimized.as takes 104ms and gives back 2402 verticles

welding a Cube with Subdivisions 30 x 30 x 30:
Weld.as takes 40526ms and gives back 5405 verticles
WeldOptimized.as takes 200ms and gives back 5402 verticles

welding a Cube with Subdivisions 100 x 100 x 100:
Weld.as - didnt care to test this…will take far to long…
WeldOptimized.as takes 3114ms and gives back 60002 verticles

the WeldOptimized.as also lets you choose if you want to keep your uv intact, and if you want to set the autoDeriveVertexNormals to true, or to use the old normals (shared normal will be the mix of the old unshared normals).

besides the WeldOptimized.as i created another class called WeldByAngle.as
it works just like the WeldOtimized.as, but has one more parameter “maxAngle”(0º-180º). whenever a shared vert is calculated, the angle between the normals of the two faces sharing this verticle is calculated, and if it is bigger than “maxAngle” the two faces will not share the verticle.
This is exactly the way that the Phong-Tag in Cinema4D deals with sharedVerticles.

Hope you like it.

Thank you. I believe Fabrice will want to take a look at this!

Fantastic!
(I haven’t looked at it yet tho) but it was on my todo for this week, i’m sure its gonna be a great read!

I plan however to add the angle check per axis, as a single threshold fails on my test model. (similar to a case posted on this forum a few days ago)

Will look at it today or tomorrow and get back to you.

hi Fabrice

i hope my code can save you some time…

can you give me more information about that issue with the angle calculation ?
i didnt realised any errors in my meshes this far. i have the same function done in python when exporting from c4d, and as far as i can tell, the meshes seams to appear correct in away3d.

ive made some tests welding a skinned mesh (polarbear=ca.8000 verticles) while keeping the skinning data. if i weld it completly (no uv-map or angle-calculation), its data is below 2000 verticles and the skinning still works correctly. the fps of my debugplayer goes up from 42 to 60.
problem is that this complete welding breaks your uv map.
if i try to keep the uv-map or calculate welding by angle, not all verticles will have the correct weights applied.

example:

all verts of a mesh are not shared. (vertcount = tricount*3)
vert1, vert2, vert3, vert4, vert5, vert6 are at the same 3d-position.
if we dont care about uvs or phong breaks, we only would need vert1.
in this case we can leave the skinning data of vert1 as is and delete vert2-vert6 and there skinning data. this works.

due to a uv-map, we could need two verts at the position of vert1.
so we would end up with keeping vert1 and vert2.
in theorie vert1-vert6 should have the same skinning data (since in same 3d-position).
problem is that vert1-vert6 seam to have different weightdata.
so if i try to delete vert3-vert6 and their skinning data, i end up with vert1 and vert2, but both having slightly different weightdata.
the order of Joints for the weightdata for vert1-vert6 seams to be the same.

any thoughts about that ?

forget what i said about the weights.

was just a simple mistake in my code…

now my classes can handle skinnedSubmeshes

for the polarbear.awd:

time the weld takes: 200-250 ms

fps without weld: constant 38 fps in debugplayer - 8688 verticles

fps with weld: constant 60 fps in debugplayer - 1666 verticles

if you want to test yourself, just add this lines of code to the Intermediate_CharacterAnimation.as (inside of “onAssetComplete”)

hi fabrice

did you had a look at my classes ?

i could really do with some feedback, so please tell me (even if you think its useless)

sorry, was too busy this week. (exporters package among other things)
As I need this feature production ready for a project that should start any day now, I’m surely gonna return to the Weld class…

Yes I’ve looked at your classes, and first I saw was that my assumption of slow dictionaries was false. Just because of this, I know at least 3 classes that will soon get an update if they turn out to be indeed faster…

I was already busy on an update for the class, before you posted it. Done some changes, probably for the very same reasons you got once you started.
And then Richard pinged me, saying some interresting code was posted…

I will get back to you asap. I promess!

Hi Fabrice,
I just tested the WelbByAngle Class from 80percent and it works fine. Since I was not able to get a result like this with any export from 3ds max, could you consider integration of WeldByAngle in prefab3d? Would be great!

Thanks a lot! You guys do a great job!

Best regards,
Philip

I was planning to regroup features in one class, but got distracted by others things… I could certainly add this option in no time, if 8oProzent agrees, I could add it to the next update.

80prozent agrees!

ok then

Done! Speaking about responsive development huh

Wow, that was fast indeed I am looking forward the update. Thanks a lot!

i weld it completly (no uv-map or angle-calculation), its data is below 2000 verticles and the skinning still works correctly. the fps of my debugplayer goes up from 42 to 60.

_________________
rs gold|wow gold|cheap rs gold|Runescape Gold