WIP 3D Engine (Update : v0.07 screenie preview) [v0.06]

[Hezad]

I'll try to calculate the normals by myself while generating the sphere then. But those normals should be okay since I have a procedure which precalculate automatically all normals :p

thanks for the advice anyway, I'll try it

[hellfire]

Hazad, you are creating 3 independant vertices for each triangle.
Later you're calculating the per-vertex-normal by averaging the normals of all triangles adjacent to the a vertex.
But there is just one triangle (because there are no shared vertices) and it's the same for each vertex of triangle.
So you got exactly the same normal for each vertex of a face - which results in perfect flatshading

You probably do not want to store three (unshared) vertices per triangle, but instead store each vertex only once and, additionally, create a triangle-table storing three indices into the list of shared vertices.

This will save you quite a lot of transformation-work because in the average case a mesh has only half as many vertices as triangles.
Since you're now creating 3 vertices per triangle, you have six times as many vertices as are actually required...

Example:

Vertices:

Code: [Select]

Vector vertices[12]= {
  0, 32.647, 0,
  29.2, 14.6, 0,
  9.0233, 14.6, -27.771,
  -23.623, 14.6, -17.163,
  -23.623, 14.6, 17.163,
  9.0233, 14.6, 27.771,
  23.623, -14.6, -17.163,
  -9.0233, -14.6, -27.771,
  -29.2, -14.6, 0,
  -9.0233, -14.6, 27.771,
  23.623, -14.6, 17.163,
  0, -32.647, 0
};

Faces:

Code: [Select]

int triangles[20*3]= {
  0, 1, 2,
  0, 2, 3,
  0, 3, 4,
  0, 4, 5,
  0, 5, 1,
  1,10, 6,
  2, 6, 7,
  3, 7, 8,
  4, 8, 9,
  5, 9,10,
  6, 2, 1,
  7, 3, 2,
  8, 4, 3,
  9, 5, 4,
 10, 1, 5,
 11, 7, 6,
 11, 8, 7,
 11, 9, 8,
 11,10, 9,
 11, 6,10
};


[Hezad]

Hey

I totally understood this :

You probably do not want to store three (unshared) vertices per triangle, but instead store each vertex only once and, additionally, create a triangle-table storing three indices into the list of shared vertices.

thanks to the examples, and I like it :p

But there's something I don't understand :

Later you're calculating the per-vertex-normal by averaging the normals of all triangles adjacent to the a vertex.
But there is just one triangle (because there are no shared vertices) and it's the same for each vertex of triangle.

Why is there no shared vertices ? I mean, even if I don't use a vertex list/triangle table for now, there's a routine in my precalc_normals procedure which finds which vertex is shared with another (The way I do this is surely not the best way to do it, but I was expecting it to work at least :p)

And a last question, about the vertex list and the triangle table : Do you recommend me to use this approach in all the engine ? Or just while generating objects ? Because using it all along the code scares me a bit : I should change almost all the code when it comes to vertex handling !

[hellfire]

My mistake, in my explanating I forget that you don't have indices at all.

In your PreCalc_Object_Normals function you check for each vertex of a triangle, if there's any other triangle with the same vertex-position. In theory this should work - but it doesn't because in SamePnt you're comparing two floating-point values for equality - which fails.
That's because the fpu internally calculates at a precision of 80bit while you're storing values at single(32bit) precision, so you can assume every assignment to a variable as rounding.

Reordering two iteration of your loop results in something like this:

Code: [Select]

u1 = round (phi/PIx2)
u2 = round ((phi+dPhi)/PIx2)
phi= round (phi+dPhi)
...
u3 = round (phi/PIx2)
Here u1 and u3 are not equal because of different rounding (the difference is rather small though).
That's why you can't find any adjacent triangle when calculating the normals.

The usual aproach for comparing floating-point values is something like this:

Code: [Select]

if abs(a-b)<EPS then equal

about the vertex list and the triangle table:
Do you recommend me to use this approach in all the engine ?

Absolutely yes because you have much few vertices to transform and require less memory.
When you're at some point going for 3d-acceleration, this approach is also supported in hardware (index-buffers).

Another thing I noticed is that your vertex-structure is rather big. I recommend to split it into multiple arrays because you're now piping a lot of useless data through the cache when accessing a vertex (the polyfiller for example is not interessted in untransformed 3d-coordinates or normals).

[Hezad]

rah supa k++ to you ^^ it works perfectly ! thanks a lot for finding the problem. I didn't know this stuff about rounding, I'll remember that !!

Absolutely yes because you have much few vertices to transform and require less memory.
When you're at some point going for 3d-acceleration, this approach is also supported in hardware (index-buffers).

Another thing I noticed is that your vertex-structure is rather big. I recommend to split it into multiple arrays because you're now piping a lot of useless data through the cache when accessing a vertex (the polyfiller for example is not interessted in untransformed 3d-coordinates or normals).

Noted, I'll work on that then

[Shockwave]

Nice image

I thought it was a normals problem, glad you got it sorted out Can't wait to see it working!

[Hezad]

Hey Well, I just finished to implement Mip Mapping

Nice image Smiley

thanks ^^ I hope you'll like this version !

Well it's not filtered yet (or yes it is, but just an average of 4 colors on each stage) and there is still some flickering (not much though, excepted on the checkered sphere, it's awful oO but I think it's a problem with my MipMap generation routine).

I decided to set version numbers from now on, it'll be easier (even for me) to see what's new and when. Oh and I already heard some complaints (not here ^^) about the fact I don't respect the version number norms but whatever

So, here is the changes list :

v0.02 Changes List



MAJOR :

- Added MipMapping handling !
  > Set_Mipmapping(ON/OFF) to set it.. well.. ON or OFF
  > LOD bias constant for now
  > No filtering yet (Bilinear planned)

- Added GenerateMipMap() procedure.
  > Generates MipMap GFX or loads it if file exists.

- Added Light Fall Off coefficient.
  > Permits Light intensity to fall off with distance between objects and lights.

- Added Object.GenerateSphere() procedure.
  > GenerateSphere (x0, y0, z0, Radius, Subdivisions)



Minor :

- TSLine and GLine subs replaced with macros.
- Some minor optimization.

I should work on optimization and on the vertex list / triangle table hellfire spoke about but I don't know yet how to start (I tried the vertex list/triangle table, but when I do this, I lost all information about U,V coordinates, normals, etc.. but I'm thinking about it ).
And concerning pure optimization, I still have lot of work to do, I haven't converted singles to integers, and I surely have some divisions/multiplications I could precalculate ...




edit : This version crashes on some computers ..

[Shockwave]

It locked up here after opening the screen unfortunately mate.

Illegal array access? Drawing something off screen?

[Hezad]

Argh, problems coming ^^

Hum .. Could you compile the code without using Mip mapping please ? (beginning of test_gouraud.bas, change Set_MipMapping ON to MipMapping OFF). If you can't compile, I'll compile a version without mipmapping.

Drawing something off screen?

Hum .. Well, normally, it shouldn't be possible thanks to clipping

Illegal array access?

or pointer.
That would be much more probable since the mipmap processing uses different textures sizes, it could use a wrong size and look for a color outside the pointer/array .. But now, why does it work for me then ?

thanks for feedback


edit : aargh wait a minute ! I just remembered the fact that the mipmap pointers are not deallocated !! I forgot It could be the problem source I guess ? I fix it and I repost the .rar here

[Shockwave]

I cant compile it unfortunately since I have an old version of FB here, but what you said about pointers sounds likely to be the cause.

Something else that you should look into are any new floating point stuff you've got in there too.

I once had a bug whereby I was trying to convert a floating point varialbe into a colour value eg;

rgb (float,float,float)

I hadnt realised they were floats and it was crashing, it took me a while to figure it out.

PCs are strange like that.

I can code super illegal shit on my notebook, writing past buffer limits etc and it just runs it happily. On here it dies straight away.

I'll test your program on the laptop in a while too

[Hezad]

I cant compile it unfortunately since I have an old version of FB here, but what you said about pointers sounds likely to be the cause.

No problem, I'll compile a "without Mipmapping" version

Something else that you should look into are any new floating point stuff you've got in there too.

I once had a bug whereby I was trying to convert a floating point varialbe into a colour value eg;

rgb (float,float,float)

I hadnt realised they were floats and it was crashing, it took me a while to figure it out.

PCs are strange like that.

I can code super illegal shit on my notebook, writing past buffer limits etc and it just runs it happily. On here it dies straight away.

ah computers.. I'll check for the floats and colors stuff

I'll test your program on the laptop in a while too Smiley

cool grazie ^^


Now, I think I have something concerning the bug .. I wrote a destructor for my texture type to deallocate all the previously allocated pointers at the end but strangely, it makes the program to crash. It must be a sign ><

[Clyde]

Something I noticed in your source you are using reserved keywords for commands etc, eg color in your type, and also pos. It's a good idea to call them something else, as the compiler may act up on you.

Also not sure if this'll work.
 

Code: [Select]

#include "fbgfx.bi" ' for constants

I'd put the comment part above the include. Also I tend to use #Include Once "includefile_example.bi".

Also, im not sure if it matters and theres a default, for calls to subs, with using ByVal before your variable name and its definition. eg Declare Sub Yo( ByVal PosX As Integer, ByVal PosY As Integer ). As in older versions there was either ByVal ( By Value ) or ByRef ( By Reference ). not 100% sure if that's been done away with in the newer FreeBASIC version.

[Hezad]

Hey

About the reserved keywords, I think they can be used in user defined types as variables but not as subs (unless you undef them). But you're right, I should have good habits :p

About passing variables ByVal or ByRef, I think its ByRef by default on FB 0.18.xx (the version I use), but since other people could compile with other versions, and since the default may evolve in the next versions, I should always specify ByVal or Byref (what I don't do everywhere actually)

These are reasonable advices and I'll follow them right now, it may help for debugging

Concerning the comment on the include statement, I only use fbfgx.bi for the scancodes constants and for now I only use them in the test source file (and this part works).

Thanks for (having take ? taken ? taking? arg I don't know ><) a look in the source

[Clyde]

No worries mate, my few pennies worth that may assist you dude.

[hellfire]

I can run the binary but when i press esc, visual studio asks me to select a debugger 
When I recompile the source (with FreeBasic 0.2) it crashes right away,
when I disable mipmapping it works fine.
Error checking (-exx) reports:

Aborting due to runtime error 12 ("segmentation violation" signal) in "materials.bi::LOADMIPMAP()"

Some notes about mipmapping:
What I've understood from a quick look at your source-code, you're now selecting a mipmap-level depending on the depth of a polygon.
Generally it's true that if a polygon is further away, it's also smaller and needs less texture-precision - but it's not a very clever approach (but some ps2 games use this way because the hardware doesn't support mipmapping and it's easy to do).
If you, for example, look from a steep angle at one side of a cube, this side is very narrow and only needs a low texture resolution - although the polygon might be very near to the viewer.

So let's assume you're interpolating texture-coordinates linearly (which is inevitable when you stop doing perspective divide for every pixel), a better approach is to look at the deltas for interpolating the texture-coordinates u & v across the scanline.
For example if one delta is >= 2.0 you'll always skip one texel when advancing to the next pixel. In such case you can savely use a mipmap with half the size.

For generating the mipmaps, you can simply scale the "current" mipmap to half the size on-the-fly (a simple 2x2 filter) so there's no reason to save all mip-levels.

[Hezad]

hey hellfire thanks for the report !!! I tried to run with -exx but (I must be lame ^^) I never found the report

Okay, so it confirms what I was thinking, a segmentation violation. And in LoadMipmap. erm....



erm ...


*brain on fire* ^^

Okay I recap :
- A segmentation fault in LoadMipMap (so, surely pointer error or array error ... you have to know I use an array of pointers, in the new Texture Type (which handle MipMapping) in this way :

Code: [Select]

Texture.MipMap(NbLODS) as integer ptrin which I keep the mipmaps image ptr

- A crash once the gfx screen opens (even on my computer this time) when I set the destructor of TextureT to destroy all the GFX contained in this type (Original size + MipMaps)

erm.. I continue to search in LoadMipmap



edit :
another thing you have to know, I store my images in integer ptrs. So to load bmps, since bload don't work with this kind of pointers as-is, I must do that :

Code: [Select]

Bload FileName, MipMap(CurrLOD)-8
If I get off the "-8", it don't work. It may come from here too since I use a cheat to load the bmps. But if it's the case, why did it work before and not now ?

[hellfire]

why did it work before and not now ?

Luck? 

[Hezad]

.. In those cases, I totally hate luck ><

Well so I guess the next step is a custom Bmp Loader ..

[Jim]

In your mipmap code, I think you need

        _pow2  = 1/(2^(CurrentLOD+1))
instead of
        _pow2  = 1/(2^CurrentLOD)

And remove the -8 from the bload
And change this bit
            MipMap(CurrLod) = Callocate(CurrX*CurrY-1+1000,Sizeof(integer))
I think the bload needs some more space for some reason.

Works for me then.

<edit>Look at the sample codes for bload and imagecreate
http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgBload
http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgImagecreate
Seems you should use ImageCreate instead of Callocate and let FB worry about the image metadata size that it needs.

Jim

[Hezad]

Ah ! Thanks a lot for that ! I'll upload the new exe with this post since I can't debug it at home (how to debug something which is working on your computer ?..  )

strangely, getting off the "-8" on :

Code: [Select]

Bload fileN,this.GFX-8makes my program to crash but inversely, the one you specified :

Code: [Select]

Bload MIPMAP_FOLDER+filen+"_MipMap"+str(CurrLOD)+".bmp",MipMap(CurrLOD)-8doesn't make me crash if I get "-8" off.

<edit>Look at the sample codes for bload and imagecreate
http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgBload
http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgImagecreate
Seems you should use ImageCreate instead of Callocate and let FB worry about the image metadata size that it needs.

Well in fact I totally agree, I should use ImageCreate with Any ptrs instead of Callocate with integer ptrs, but I started to code the engine using integer ptrs since I use them to directly write on the screen buffer. (And since the pointers returned with imageCreate have some headers and/or data before the image data, I don't know how to deal with them, I don't really want to use pset or put excepted on pre-rendering operations (like mipmap files writing))


Here are the new exes with those modifications (2 versions)

(too large to be attached here, links below)

- Engine With Mip Mapping
- Engine without Mip Mapping


In those versions, the GFX destructor is commented since it stills make me crash.