Beta release 1.9.8b

Post by **Kjell** » Sat Jul 25, 2009 1:24 pm

Sigh,

Said it before .. will say it once more. This is why there should be a generic MatrixTransform Component ( or Matrix variable type + operations ) instead of specific Mesh / Bitmap etc. components.

And you can already use the MeshTransform Component in the exact same way as I used it to create solid meshes for Bitmaps. Not that you would want to ... when you're doing 2D, you're only rotating over the Z axis ( plain & simple sin / cos ).

Besides, as long as there is no render-to-texture / FBO's, you still need to write all the BitmapTriangle / BitmapCircle / BitmapStar etc. ( please do not implement these kind of components ! ) functions yourself.

Anyway, I should try to stop commenting to Mesh / Bitmap generation related threads

K

kattle87 · Post by **kattle87** » Sat Jul 25, 2009 1:45 pm

last offtopic post, I promise.
Kjell, could you delineate how this matrixtransform component could work? Since I can't find any way to make this work on every other component, actually.
And no need for FBOs, really. We just need a better handling on the load bitmap and the bitmap combine.

jph_wacheski · Post by **jph_wacheski** » Sat Jul 25, 2009 1:47 pm

Yeah its fine to do this stuff yourself,. if you know how, but what about he kids that just want to build a simple game, and not write there own functions, or have to translate bitmap data through an array to translate it in the bitmap?? (rarther abstract)

We do have the superforms for a basic building block,. circle, star, square, etc, etc. a translate component just seems logical and usefull,. say I want to build an animation strip from a few elements its not so simple without a translate,. .

A lot of the things that I suggest are not so much for me, (but I will likely use them if added!) as they are to just make ZGE more approchable for more people,. . I learned a long time ago that everyone else does not know the things I do,. however I often operated on the assumtion that they did or perhaps should,. this often frustrated me untill I realised it. Remember Kj you are a very smart and skilled guy,. sadly not so much for the rest of us monkeys

thats one reason we lov u.

Post by **Kjell** » Sat Jul 25, 2009 2:12 pm

What about the kids that just want to collide with their environment ( almost any 3D game needs this .. Ocarina of Time, Mario 64, Metal Gear Solid, Bioshock .. you name it ).

Anyway, I'm just saying that we should try to implement missing low-ish level stuff first, instead of a bunch of specific components that are useless unless you want to do the exact thing these components do. And I'm more then happy to help out people with writing scripts for niche stuff they want to do .. if that means it will keep it out of the main build.

So, here you go, a basic ( unoptimized ) iterative Bitmap generation setup

We could use a BitmapSetPixel ( int X, int Y, vec4 Color ) component though .. looping through the whole Bitmap each pass is quite slow.

By the way, for this specific example it would probably be faster to store the data into a 3D Array first, and then generate the final Bitmap from that + some 2D sweep 'n pruning instead of calculating the radius each pass ..

K

kattle87 · Post by **kattle87** » Sat Jul 25, 2009 4:40 pm

Bug: Normals are not updated using the transform component

Solution: Add an autonormals property or apply the micropatch I sent to Ville... (Just added 2 lines of code).
EDIT: my solution is still not correct. The problem is terribly more complicated than one could expect... Let's say that if you want to do the things in the right way, you need to recalculate normals from scratch. So should we add a "autonormals" property to this component, too? Or maybe an "approximation" could still be fine?

More: I'm still squeezing my brain about those matrices... I know lots can be done with them but we need a coherent way to implement them. Especially for usability for the end user.

And BTW I'm not so sure about multiplying the matrices when using the accumulation option... Some of those values are offset values (the ones on the last column) and I think we should add them not multiply them.

Post by **Kjell** » Sat Jul 25, 2009 6:27 pm

Hi,

Rotating the normals requires the same technique as rotating vertices ( try it using GLSL ). And other apps do it like this.

K

kattle87 · Post by **kattle87** » Sat Jul 25, 2009 6:55 pm

Wrong

this is fine until you do not use the scale property. This is because the scale property in ZGE can make 2 surfaces "slide", so the normals won't be correct any more. Both if you scale adeguately or you do not.

Post by **Kjell** » Sat Jul 25, 2009 7:00 pm

Hmm,

That picture looks perfectly fine .. apart from the normals not being normalized ( normalize() in GLSL ), but OpenGL doesn't mind that.

K

kattle87 · Post by **kattle87** » Sat Jul 25, 2009 7:06 pm

this is the approximation I'm computing

but if you look carefully at it, you will see that the "normals towards up" are not normal to the upper surface, because they should be like this:

Post by **Kjell** » Sat Jul 25, 2009 7:11 pm

Ah,

You're right .. it's a error in the Transform calculation. The scaling should be Object-Aligned ( just like translation ) instead of Axis-Aligned. So the vertices are positioned incorrectly to start with.

@Ville : Apply the scale and translation to the vertices first, then the rotation matrix.

K

kattle87 · Post by **kattle87** » Sat Jul 25, 2009 10:23 pm

Well, actually, this might be difficult to do since the components are made so that the scale property is part of the generic mesh component, so it does work the same for every mesh producer. And scaling before creating a sphere might be quite not useful, so we can't change that.
Still, I think we might really need to make some design discussion before getting this producer out of beta, also because it is definitely needed and quite fundamental for mesh producing

Post by **Kjell** » Sun Jul 26, 2009 9:25 am

It's simple enough to do using script, so it shouldn't be all that hard in the source either. Attached is a image illustrating what happens using the MeshTransform on the left, and what should be happening on the right with a Box that is being scaled by 2,1,1 + translated by 1,0,0 + rotated by 0,-0.125,0 as seen from a 22.5 degree tilted angle.

K

Post by **VilleK** » Sun Jul 26, 2009 4:22 pm

I'm with you that something needs to be done with the normals. But about the transformation order: I apply the transformations in the same order as the implicit-meshes components as I was sure that was the desired order. Rotation first around objects axis, then scale and transform. Isn't this right?

Post by **Kjell** » Sun Jul 26, 2009 6:08 pm

Hej Ville,

The order doesn't matter a whole lot, as long as you apply the scale transformations in local space, not in world space ( this is what is wrong ). The only benefit of doing this in the order of scale -> translate -> rotate is that you can skip multiplying scale / translate with the local matrix when the local rotation equals the world.

K

Post by **VilleK** » Mon Jul 27, 2009 9:18 am

Kjell, thanks for the explanation but I'm still not quite following you. Is there really a "world space" involved here? The transformation is done on the mesh vertices which always are in local coords.