Oysi's 3D Rendering & Physics Engine

[OuTopos]

Awesome stuff!

There are these strange artefacts that occur when you write to the same canvas you are reading from, from a shader. Meaning that when I get the depth and match it against the depth already stored, I get problems when I write the stored depth back into the buffer/canvas.

Have you found a workaround or fix for this?
I have the same problem.

[slime]

OpenGL has undefined behaviour (meaning drivers could possibly crash the program) when you do that - so you'll have to find some way to do what you want without sampling from the same canvas you're rendering to.

[OuTopos]

Thanks for the answer.

Not sure how to do a depth buffer without sampling from a canvas and writing to it.
Do you know of any other solutions?

[Oysi]

Made the normal mapping work more properly, and on the cubes themselves.

Have you found a workaround or fix for this?
I have the same problem.

Unfortunately, I have not. I've tried a ton of stuff, but now I just thought of something I have not yet tried... brb

EDIT:

=(



I have no idea how to do it. I'm thinking it's impossible. =/ That is, without calling setCanvas twice per polygon, which worked, but caused the fps to drop to 3 or so.

[Germanunkol]

Your normalmaps look inverted to me. The Mortar shouold not stand out, but instead be "lower" or "further inside" than the bricks, I think.
http://en.wikipedia.org/wiki/Mortar_%28 ... mortar.jpg

Other than that, it looks brilliant.

[Oysi]

Oh, that makes sense. Haha, I didn't even think about that. =P

Tried a small test:

Left side of the picture has the x inverted
Bottom side of the picture has the y inverted
So the top right is the original



Not sure if you can tell, but I can see that it's either top right or bottom left. Either (1, 1) or (-1, -1). So here are those two side by side:



Just to figure out if it was the texture itself or my parsing of it, I tried a different normal map:



So I can safely conclude that it's the texture. =)

Also, thanks.

[RamiLego4Game]

Your 3D Lib is so awesome , i need your help , currently i'm working on a program using love2d, it's emulator for computercraft (minecraft mod)
i need to emulate the turtles , so i need 3D Lib , I don't need Physics for it, Can you help please ?
Email : ramilego4game@gmail.com
Skype : RamiLego4Game

[ArchAngel075]

Im having fun playing around with 3D rendering thanks to Oysis tutorial,
infact im working on a lil' project that might let one import and render defined 3D models from lua tables...

The only issue im now struggling is , Oysi you showed in tutorials how to rotate the scene around a where the viewport is,
BUT how does one rotate a polygon (say a cube) locally...

Note i have access to a BEAUTIFUL matrix3 library that has let me speed things up alot (i can to matrix*matrix and get the proper result asif it was simple maths like 1+1...) so i have all global scene rotations using rotation matrices but im missing that crucial local rotation matrices... any links you can point me towards so i can read up would be helpful


EDIT :

Ok scratch that, after thinking about it i figured out a way :
First store any translations made to the polygon, easily done using 3 values to represent x,y,z of total translation
Then to do local rotation you first translate the polygon using the inverse of the stored translation
do rotation as one would normally, but only on that polygons vertexes
lastly translate the polygon using the translation stored (not the inverse)

I have a working rotation around selfs center on Y axis, now to toss in the others and do that annoying sorting for drawing...

the only issue is this assumes ALL polygons define thier origin as {0,0,0} regardless, though if I get the difference of their origin to the center it might be ignorable..i think (untested this part)

[Oysi]

@ArchAngel
In actual 3D graphics, it's a bit different. I should mention that the technique of going through each vertex and replacing it with the transformed vertex is not used anymore. The reason I did that is because it's the easiest way, doesn't require any matrices, and since everything is on the CPU anyway, there isn't much of a difference in terms of speed.

So, the way it works in actual 3D graphics is you first off have a view matrix. This is essentially your camera (or more correctly, the inverse of it). It determines how the scene is to be transformed before it's rendered. So it transforms the scene into view space coordinates, where -z is the depth, and so you can do the projection stuff on that (although that is actually done with another matrix, but I won't get into that). So before a polygon is rendered, it transforms each vertex by doing viewMatrix * vertex. But this only gets you as far as we've already gone. So the way objects have their own positions and rotations is through another matrix, called the model matrix. This is almost just like the view matrix, except it only applies to the vertices of that specific object. So the transformation of each point becomes viewMatrix * (modelMatrix * vertex).

But this can be simplified, because you can combine transformations by just multiplying the matrices. You can also pop in the parenthesis any way you like, so you get: modelViewMatrix = viewMatrix * modelMatrix, and then you apply modelViewMatrix * vertex for the vertices of that object.

The reason why you actually want to use this model matrix is because you can do any transformation on the object, with it. You can position it anywhere, you can scale it to any size, you can rotate it. You can even distort it in some crazy way if you really want to. All of this just by changing the model matrix.

This is sort of what I do for my cubes. Except, since it's all on the CPU, I do some things differently for maximum speed (4x4 matrix * 4x4 matrix is extremely slow). What I do is use a vector for position, and a 3x3 matrix for rotation. So when the object rotates or translates, I change those values, and change the vertices stored in the object. These are the vertices that are used for the rendering (and physics).

But yeah, you can also translate to the position, rotate, and then translate again but with the inverse. I have thought of what to do in my next 3 or so tutorials, which will just go more into matrices, and explain some of this stuff, and go over to using the viewmatrix instead of changing every vertex. So stay tuned for that, haha. =P

[ArchAngel075]

Oh i have seen many times this modelMatrix pop up in my readings,
Ill probably see if i can use that instead later..i spent 18 hours without sleep programming and crashed haha...


Im just curious.
When rendering my models, at the moment to simplify things i store with each polygon (I call these polgons 'artifacts' for some strange reason) a extra set of data that groups vertexes into set groups that define a "face" on my artifacts. say a cube will then have 6 faces each face 4 vertexed.

To render my artifact i then grab each face group and build a polygon from those vertexes of that face and draw.

Im absolutely sure this is wrong, the main reason is I would like to do per face texture application so that a model using my program would specify its original vertexes and face groups and then for each face group specify a texture to use.

Though this is creating a mission in terms of (i think its called) z-sorting...Some faces are really attention craving and like redering infront others when they shouldnt...

Im sure you perhaps have a more clean way of wrapping an image onto the 'artifact'