gbadev.org forum archive

I'm having problems with the .3ds file format, and back/front faces. I wrote this loader for Wii/GC, PC for mainly debugging reasons, and while it hasn't been ported to this yet, the loader can easily be ported to DS.

Many of the faces that are supposed to be back faces, they're front faces, and the ones that are supposed to be front, they're back faces.

Click here for the gcdev topic about this. How do I fix this glitch,(which is caused by a flaw in the .3ds format)
on-the-fly when the model is loaded?

Last edited by yellowstar on Wed Jul 16, 2008 5:52 pm; edited 2 times in total

just a guess...but maybe the winding is backwards? it could be laying the verts out in clockwise order instead of counter-clockwise....or vice versa.

I totally agree with doing it beforehand. Doing it in the loader is wasteful and I think it might interfere with triangle strips if you try to do it in place rather than recalculating all the strips too.

I'd recommend using another app to reorder the verts if you can. Try blender or wings3d or something.
_________________
- nanou

Holland wrote:

just a guess...but maybe the winding is backwards? it could be laying the verts out in clockwise order instead of counter-clockwise....or vice versa.

I already tried reversing the winding on all the faces, with no success.

Blender will take a while to download. How would I fix the back/front faces in blender? This Wiimote model, it's a .obj model I converted to .3ds myself, so re-exporting probably won't help.(I converted it with Anim8or)

yellowstar wrote:

Holland wrote:

just a guess...but maybe the winding is backwards? it could be laying the verts out in clockwise order instead of counter-clockwise....or vice versa.

I already tried reversing the winding on all the faces, with no success.

i figured as much...but it was worth a shot. most of the time when i can't figure something out it's the most obvious thing wrong...and i tend to neglect looking for the obvious. :/

Instead of doing vertices for a polygon in the order 0,1,2,3 try the order 0,1,3,2.

Otherwise, I'm not an expert in GCdev but I'd guess there is a basic quad and triangle drawing example. What I suggest is get that working. Then create quad and triangle with the same vertex values in 3ds and load those. Then you can manually compare the difference and go from there.

.3ds only support triangles.

Could you post a picture, because it sounds like only some of the triangles have flipped normals... ?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Normals aren't even used. When I try using normals, it doesn't help. With my normal calculation code,(.3ds doesn't have normals data either)
it even crashes, with some models.

I can't get a screen shot of the Wii version, since my vacation is over, but I can get a PC screen shot. With the PC version, the displayed model looks worse than on the Wii. One of the problems with PC version is that the white Wiimote texture looks like lime. Screenshot

Blender finished downloading, so how do I fix this with Blender?(I still want to know how to fix this in my loader, however)

You get "flipped normals" (or better: surfaces) by changing the winding order, too. ;^)

What I do in such cases (when exporting from Cinema4D using Wavefront .obj, in my case), is: Load the model into Milkshape, reverse vertex order and export it back.

But if your implementation fails by "randomly" reverting the vertex order, then it is seriously broken.

It would help, if you posted an image for comparison. Maybe a wireframe or a non-broken rendering. ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

silent_code wrote:

What I do in such cases (when exporting from Cinema4D using Wavefront .obj, in my case), is: Load the model into Milkshape, reverse vertex order and export it back.

But if your implementation fails by "randomly" reverting the vertex order, then it is seriously broken.

It would help, if you posted an image for comparison. Maybe a wireframe or a non-broken rendering. ;^)

Milkshape isn't an option for me, it's shareware, and the trial period passed ages ago.

Does anybody know of any .3ds loaders, that also display textures?(Textures in either .jpg or .png)

The screen shot from a 3D Modeling program will look WAY different then this. I wonder what would happen if I would use Blender to convert this? With the loader on Wii, this glitch is only noticable if the model has a texture. It's difficult to notice if the whole thing has the same color/material. A wrench model rendered fine with my code.(But that didn't have any texture, just two materials)
By the way, this Wiimote model has ~12004 triangles.

It's difficult to get the model/camera rotated the exact same way as in the screen shot... I tried exporting the model from Blender, but the now the model doesn't even appear anymore...

Theres lots of info out there on this.

Firstly, 3ds is a lousy fat format, you don't want it anywhere near your DS, or wii for that matter.

Secondly, what most commonly occurs is an objects (nodes) scale matrix in 3dsmax ends up with a negative component, causing the model to be rendered inside out. Max automatically flips the tris in the renderer when it detects this, but doesn't correct for it when saving to .3ds.

In max, the procedure to correct it is to apply a Reset Transform modifier to the objects, and then (optionally) collapse the stack.

TwentySeven wrote:

Firstly, 3ds is a lousy fat format, you don't want it anywhere near your DS, or wii for that matter.

I'm not going to keep using .3ds after I get this loader working. Before I started working on this loader, I didn't have any issues with the .3ds format, but since then, I now dislike it. Some very large models, triangle-count wise,
never loaded.(On Wii) It never finished the .3ds loading. And this glitch with the back/front faces, that caused me to dislike it even more.

I guess I should check what the value in that MASTER_SCALE chunk is...

Code:

MASTER SCALE 1.000000

Well, master scale seems fine... There may be other scale values, too, however.

EDIT:
Is there any other scale values/chunks?

There should be a transform matrix per node.

You'll have to extract the scale information from it (nontrivial off the top of my head)

are you using glRotatef? for some reason, it's flipped on the nds as opposed to Linux/Win/OSX.

edit: nvm, dunno why you would use glrotatef. I hear that the max limit of vertex coords on the ds is 8; is your model large?

JYC376 wrote:

are you using glRotatef? for some reason, it's flipped on the nds as opposed to Linux/Win/OSX.

edit: nvm, dunno why you would use glrotatef. I hear that the max limit of vertex coords on the ds is 8; is your model large?

Would you mind elaborating, because I don't think it's very clear what you are talking about? ;^)

Your wording is a bit misleading. I think it would be better to write:
The range of each vertex coordinate component (x, y, z) is ca. -8 .. +8.
Is that what you meant?

And glRotate*() works fine for me... am I missing something?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

silent_code wrote:

JYC376 wrote:

are you using glRotatef? for some reason, it's flipped on the nds as opposed to Linux/Win/OSX.

edit: nvm, dunno why you would use glrotatef. I hear that the max limit of vertex coords on the ds is 8; is your model large?

Would you mind elaborating, because I don't think it's very clear what you are talking about? ;^)

Your wording is a bit misleading. I think it would be better to write:
The range of each vertex coordinate component (x, y, z) is ca. -8 .. +8.
Is that what you meant?

And glRotate*() works fine for me... am I missing something?

Yeah, that's what I meant.

At least on what I've experienced, the NDS uses the left-hand rule; that is, it goes clockwise (if the vector is pointing at you) instead of ccw on computer-based implementations. Dunno how that would affect loading a model, though...

Direct3D is also a PC (and recently XB, yeah) based API... does that count, too? Because iIrc, it doesn't use the same coordinate system as OpenGL.

PS: The NDS is also a computer (which meant to be a bunch of women back in the days, when there were no "computation machines.") You sure mean PC or Mac. ;^p (Sorry, I'm in "the mood" right now and can't help it. ;^D )
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

On PC and Wii, and sometime DS, I'm using glRotatef for rotating the model for viewing and debugging proposes. The camera isn't moved around for viewing in my code, the model is rotated.

I was going to attempt to get this 3DS Loader running on DS.(Using a model already in memory, fat will not be used for this test demo.)
But... My model and code uses png for the textures. The Wii version uses PNGU,(which uses a pre-compiled libpng built for Wii/GC)
and the PC version uses a version of PNGU I compiled myself. But for libpng, I had to use a pre-compiled library, since libpng was acting up on me when I tried to compile it myself. So, I need a pre-compiled libpng before I can get this 3DS Loader running on DS.

Also, what is the max amount of triangles/polygons the DS can draw every frame?

There is a vertex and primitive RAM, having space for 6144 and 2048 entries, which is a lot to work with! Try to push the hardware and you can create some very nice graphics!

The limiting factor here is *slightly* biased towards the amount of available vertex RAM. When rendering quad(literal)s, around 1500 can be rendered, which results in "more geometry" (would otherwise need 3000 triangles, which exceeds the primitive RAM), but 2000 quads would also need space for 8000 vertices and additionally, each quad uses up one vertex index (texture coordinates, color ect) worth more space in the primitive RAM... you certainly get where this is going to. :^)

When you flush the 3D pipeline at the end of the frame, those buffers get copied from the geometry engine to the rendering engine and cleared for rendering in the next frame.

Also, what I found out recently, the graphics command FIFO will limit rendering, if not used propperly. IIrc, it has space for 240 (single / no argument?) command entries.

If you send more geometry than can be rendered, the later entries will be dropped.

Clipped (and thereby split) primitives ("polygons") also count, so watch the limit and culled ones don't count. Rendering of one dot (/pixel) primitives can be en-/disabled. When disabled, such small primitives don't count, but can produce some (mostly unnoticable) artifacts (only in some cases, that I didn't run into, yet. ;^) )

The refresh (/ frame) rate will not drop with all features enabled and using all geometry RAM entries (vertex and primitive), but it will drop when the graphics command FIFO overflows and stalls the hardware. That can happen when using immediate mode rendering instead of displaylists (where possible), as the latter can be packed with less memory usage, use less command entries and be DMAed, which is also non-blocking (iIrc.)

Current primitive and vertex usage can be read back via registers. Also, the amount of free "render buffer lines" in the last frame can tell you if you're overdoing things. :^)

There's an overdraw limit (iIrc around 4 times) and some scanline limits, too.

I hope that helps. :^)

PS: The demo on my web site shows how to access some of the stuff (RAM entries etc.)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

silent_code wrote:

Direct3D is also a PC (and recently XB, yeah) based API... does that count, too? Because iIrc, it doesn't use the same coordinate system as OpenGL.

PS: The NDS is also a computer (which meant to be a bunch of women back in the days, when there were no "computation machines.") You sure mean PC or Mac. ;^p (Sorry, I'm in "the mood" right now and can't help it. ;^D )

I could emulate OoT on my laptop and therefore it can be called a home console. But I don't! It's PRIMARILY a computer.

If you must be in "the mood" right now, the NDS glRotate* doesn't follow the ARB standard because it rotates the angle the wrong way.

JYC376 wrote:

If you must be in "the mood" right now, the NDS glRotate* doesn't follow the ARB standard because it rotates the angle the wrong way.

There is no glRotate* on the NDS.

If you mean the glRotate* functions of libnds, try to contact the devs for a fix (Have the ARB definitions at hand) or create a patch yourself. Hell, it's open source!
_________________
Trying to bring more detail into understanding the wireless hardware

@ Maxxie: Yes, I mean libnds glRotate*(), indeed.

@ JYC376:

Well, there is also no ARB standard... and what for? After all, we don't have OpenGL for the NDS. ;^)

So, there is no "right" or "wrong", but a specification. Users seem to mistake libnds' videoGL for OpenGL. I guess that an API change (which has been discussed a lot in the past) would help, although the familiar OpenGL interface helps beginners to get started. Maybe changing the prefix to vgl would help that? Well, that's offtopic.

And I just wanted to point out that the term "computer" (especially in "computer-based implementations" - you don't state what implementations?) is a bit wide... that's all. What you seem to have meant, was "PC-based OpenGL implementations" - cars also have computers (I doubt any of them have an OpenGL implementation), but I guess that's not what you were talking about. ;^)

Please, don't feel offended.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

So the max triangles I can display on a DS each frame is 2048 triangles?

Quote:

...which is a lot to work with! Try to push the hardware and you can create some very nice graphics!

Well, 3D modeling hasn't really "clicked" for me, so I'm not very good at modeling. It would be a pain to find models on Internet with the triangle count no more than what the max the DS seems to be able to display.

Since the max tri count seems to be very low, even with a model very near the max, how well would .3ds loading from fat work on hardware?(I can't test this on hardware myself)

The problem I had with compiling libpng and libz, was that one of the libraries,(last time I tried libz was acting up instead of libpng)
when just linking with the libraries on PC, they would do some test, and force my program to exit, which I do not want.(They also printed some text on the console)
So could somebody please provide libpng and libz compiled binaries for DS?

I have seen Doom3's "Imp" model rendered three times side by side in some very basic scenery (like a box or something), so I guess that's more than enough?

Just to compare that seemingly "low" polygon (as you've seen, I like the term "primitive" a lot more) count per frame:
The XBox360 Xenos GPU is said to have a (theoretical) peak rate of up to 500M triangles per second.
The NDS has a fixed rate of 122,880 triangles per second, which isn't all that bad. Yeah, it's not 8M+ triangles per frame, but well. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Last edited by silent_code on Tue Jul 15, 2008 10:22 pm; edited 1 time in total

silent_code wrote:

The NDS has a fixed rate of 122.880 triangles per second, which isn't all that bad. Yeah, it's not 8M+ triangles per frame, but well. :^)

Is that a typo? Shouldn't that be in the thousands? I multiplied 2048 triangles by the usual DS frames per second, 60, and I got about the same number as yours, except in the thousands.

Wonder if I could get around that triangle limit... Wonder if I could display the first 2048 triangles one frame, then the next 2048 frames the next, without any visible graphic glitches, slow-down, or anything...(This would mean displaying like 4096 triangles)
Wonder how many more frames I could do this trick, until there's any glitches-slowdown...

What's the max texture size on DS? Do the textures need to be multiples of 2?

yellowstar wrote:

silent_code wrote:

The NDS has a fixed rate of 122.880 triangles per second, which isn't all that bad. Yeah, it's not 8M+ triangles per frame, but well. :^)

Is that a typo? Shouldn't that be in the thousands? I multiplied 2048 triangles by the usual DS frames per second, 60, and I got about the same number as yours, except in the thousands.

Wonder if I could get around that triangle limit... Wonder if I could display the first 2048 triangles one frame, then the next 2048 frames the next, without any visible graphic glitches, slow-down, or anything...(This would mean displaying like 4096 triangles)
Wonder how many more frames I could do this trick, until there's any glitches-slowdown...

What's the max texture size on DS? Do the textures need to be multiples of 2?

I believe he is using "." as a thousands separator, meaning a value of 122880.

Sorry, yes, I should have spotted that. Here in Germany the convention is quite the opposite (. and ,), so I mixed it up in a moment of haste. Fixed. :^)

Texture sizes are defined in an enum in libnds: GL_TEXTURE_SIZE_ENUM. It's anything p.o.t. from 8 to 1024 (I think this only works with 8bit textures), as long as they fit within the texture banks' memory.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Last edited by silent_code on Tue Jul 15, 2008 10:23 pm; edited 3 times in total

chuckstudios wrote:

I believe he is using "." as a thousands separator, meaning a value of 122880.

Well, that is the way it is supposed to be. (for those who live in a country like mine)

For me:
The . is less seperating (by size) then the , therefor . is used as the thousand seperator (which is only for readability) and the fraction seperator (which is semantical deciding, thus more seperating).

123,456,789.00 just looks wrong
123.456.789,00 looks much more reasonable
_________________
Trying to bring more detail into understanding the wireless hardware

Maxxie, in math the "." is most often called a decimal point.

Meaning the "10,000,000.1233" notation is more correct, although it should really just be "10000000.1233"

</Offtopic>

Moving back on-topic...

I'm thinking about using tga for the textures for the DS port. The tga code I wrote, for some reason it doesn't work with 640x480 textures. There's another loader which works, but unfortunately, the implemention is very basic, unlike my advanced tga code. Sometime I'll attempt to port that other code to DS from PC, anyway.

Well, with these models I was going to use, and other 3D Model web sites, I can't distribute the model without permission. I'd rather make my own basic model myself then do that.

EDIT:
This glitch so far with the models I tested, it only happens with textured models. I've forgotten how to use Blender,(to complicated...)
so I have to use Anim8or. But, the tex coord mapping isn't very good in that...

For UV unwrapping, I use and recommend the freeware RoadKill, which uses blender's unwrapping implementation. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Sorry to be one last time offtopic

TwentySeven wrote:

Meaning the "10,000,000.1233" notation is more correct, although it should really just be "10000000.1233"

There is no "more correct". Depending on the country the meaning of . and , differs. Just like driving on the right or left side of the street.
_________________
Trying to bring more detail into understanding the wireless hardware

@ maxxie: He meant that using tousands-seperators (is that the right word?) is more correctly, although it's optional. He wasn't talking about weather "," or "." should be used for it. ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

yellowstar wrote:

Moving back on-topic...

I'm thinking about using tga for the textures for the DS port. The tga code I wrote, for some reason it doesn't work with 640x480 textures. There's another loader which works, but unfortunately, the implemention is very basic, unlike my advanced tga code. Sometime I'll attempt to port that other code to DS from PC, anyway.

I have a tga loader here (included in the tar)

http://a128.blogspot.com/2008/06/ac3d-to-nds-displaylist-converter-c.html

silent_code wrote:

For UV unwrapping, I use and recommend the freeware RoadKill, which uses blender's unwrapping implementation. :^)

Isn't that a Maya plugin? I don't have Maya since it costs money.

I was thinking I'd have to re-learn Blender, at least enough to do UV mapping... (But last time I exported an .3ds model from Blender, the model was so tiny the model couldn't be seen with my code. How should I fix this?)

No, there are Maya and 3DS plugins to interface Roadkill directly in those applications, but the software itself is a standalon (open source?) freeware program. Go get it! :^)

Before that I have used LithUnwrap, which made UV jobs easier, but still a lot of manual work was required. With Roadkill (or blender, if you like it that way) I can unwrap models in mere hours, instead of days now. With a lot better UV mapping result, too. :^)

PS: You need to pin! Don't forget that! ;^D

About the sizing problem... resize the model on load time. I do that in the VSD. Later, when you use a better format, that step could be done offline when exporting.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

I found this, but where's the standalone download link?(Or is it included in the Maya/Max downloads?)

How would I detect when the model needs resized, and how would I resize the model's vertices?

You could calculate the AABB of the model, then resize it to use normalized vertex positions with that information. After that, you can resize the model to anything you want, either with the hardware (scale matrix) or manually by multiplying by an user defined scalar... you could also normalize the vertices to that scalar in one step... ;^)

RoadKill - Yes, it's one (any?) of those bundles. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Last time I tried to use normals my normals calculation code crashed my program on PC and Wii. Vertex normal calculation example code would be great.

yellowstar wrote:

Last time I tried to use normals my normals calculation code crashed my program on PC and Wii. Vertex normal calculation example code would be great.

Just do the cross product of the spanning vectors and multiply it with 1/length
_________________
Trying to bring more detail into understanding the wireless hardware

Maxxie wrote:

spanning vectors

Uh, explain what exactly you meant/what that means?

Spanning vectors are two linear independend vectors on a pane.
(Sorry if it is a wrong translation, the german name is "Spannvektoren")

On poligons that lie within a single pane (triangles do that in every case) these are just two (non parallel) vectors between the points.

Say your points are A,B and C, it can be i.e. the vector pairs (AB,AC) or (BC,AB) or (AC,AB). They all describe the pane the poligon lies on, the normals of the pane are also the normals of the poligon.
_________________
Trying to bring more detail into understanding the wireless hardware

I think I understand this now, I think.

Or not... Here's my normal calculation code, which also calculates a cross product. Could somebody attempt to find how to fix this? Or am I doing some math wrong, or something?(This must be fixed, at normals need calculated for this resizing, at least it appears to be needed.)

Code:

void CalculateNormals(stMesh *pMesh)
{
if(pMesh->pNormals!=NULL)return;

pMesh->pNormals = (stVect*)memalign(32, pMesh->iNumVerts);
stVect *normal, norm, *vect, vect1, vect2, vect3;
int vert_index=0;
float length=1.0f;
if(pMesh->pNormals==NULL)return;
memset(&norm, 0, sizeof(stVect));

   for(int cc=0; cc<pMesh->iNumFaces; cc++)
{

      for(int i=0; i<3; i++)
      {
         if(i==0)vert_index = (int)pMesh->pFaces[cc].p1;
         if(i==1)vert_index = (int)pMesh->pFaces[cc].p2;
         if(i==2)vert_index = (int)pMesh->pFaces[cc].p3;

         normal = &pMesh->pNormals[vert_index];
         vect = &pMesh->pVerts[vert_index];

         if(i==0)
         {
         vect1.x = pMesh->pVerts[(int)pMesh->pFaces[cc].p1].x - pMesh->pVerts[(int)pMesh->pFaces[cc].p2].x;
         vect1.y = pMesh->pVerts[(int)pMesh->pFaces[cc].p1].y - pMesh->pVerts[(int)pMesh->pFaces[cc].p2].y;
         vect1.z = pMesh->pVerts[(int)pMesh->pFaces[cc].p1].z - pMesh->pVerts[(int)pMesh->pFaces[cc].p2].z;

         vect2.x = pMesh->pVerts[(int)pMesh->pFaces[cc].p2].x - pMesh->pVerts[(int)pMesh->pFaces[cc].p3].x;
         vect2.y = pMesh->pVerts[(int)pMesh->pFaces[cc].p2].y - pMesh->pVerts[(int)pMesh->pFaces[cc].p3].y;
         vect2.z = pMesh->pVerts[(int)pMesh->pFaces[cc].p2].z - pMesh->pVerts[(int)pMesh->pFaces[cc].p3].z;

         vect3.x = (vect1.y * vect2.z) - (vect2.x * vect1.z);
         vect3.y = (vect1.z * vect2.x) - (vect2.y * vect1.x);
         vect3.z = (vect1.x * vect2.y) - (vect2.z * vect1.y);

         length = (float)sqrt( (int)vect3.x^2 + (int)vect3.y^2 + (int)vect3.z^2 );//integers because floats, doubles, and others would compile with this.
         norm.x = vect3.x * (1 / length);//Used to be (x/y/z) / length, but that didn't work
         norm.y = vect3.y * (1 / length);//These devisions right here cause the crash
         norm.z = vect3.z * (1 / length);
         }
         *normal = norm;
      }
   }
}

there are quite a few things wrong with your approach. the one that is probably giving you the most grief is that the operator "^" is bitwise operator exclusive-or, it is not the x to the y power operator. the easiest thing to do for x squared is is x*x.

essentially for each face you need to grab the first three points to compute the cross product - no need for the inner loop. this could lead to issues if the faces have colinear points (also referred to a tjunctions - essentiall this means the point are all on the same line) or degenrate edges (two equal points so the edge has no length).

Example (modified and untested close-to-pseudo-code version of an implementation I use):

Code:

// Clear all vertices' normals to (0, 0, 0) on load time!

for(all meshes in a model)
{
   for(all triangles)
   {
      vec3 v0 = mesh.triangle.vertex[0].position;
      vec3 v1 = mesh.triangle.vertex[1].position;
      vec3 v2 = mesh.triangle.vertex[2].position;

      v0 -= v1;
      v2 -= v1;

      mesh.triangle.normal = v2.cross(v0);

      mesh.triangle.vertex[0].normal += mesh.triangle.normal;
      mesh.triangle.vertex[1].normal += mesh.triangle.normal;
      mesh.triangle.vertex[2].normal += mesh.triangle.normal;

      mesh.triangle.normal.normalize();
   }

   for(all vertices)
   {
         mesh.vertex.normal.normalize();
   }
}

Code:

vec3 cross(const vec3 &other)
{
   return(vec3(y * other.z - other.y * z, z * other.x - other.z * x, x * other.y - other.x * y));
}

float magnitude(void)
{
   return(sqrtf(x * x + y * y + z * z));
}

vec3 normalize(void)
{
   float m = magnitude();

   if(m != 0.0f) // division by zero is super uncool!
   {
      m = 1.0f / m;

      x *= m;
      y *= m;
      z *= m;
   }

   return(*this);
}

Your program crashes, because "length" is 0 in some cases. That's due to what elhobbs has already posted: the wrong use of the ^-operator.

Cheers!

PS: I'm pretty sure it's called "divisions", but I'm also making a lot of typos, so what the heck? ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Which side of the boundaries box should be used, or how do I calculate which side to use? And after that, how would the bounaries' normals be used with the vertices' normals?

TwentySeven wrote:

There should be a transform matrix per node.

You'll have to extract the scale information from it (nontrivial off the top of my head)

How would I extract that?

One of the Wii homebrew things I was trying to do, was that I was trying to display a 3D Model of the Wiimote, and have it rotate and move in the same way the real remote being moved. However, it wouldn't budge. The orientation and accelerometer values are floats, and I think they are in the same range as normals. And I was thinking. Couldn't a modified version of this resizing concept, be used for this? The vertices would be normalized, then the verts would be rotated for the orientation, and translated for the acceleration. And then "blown-up" back to the original size. How would I rotate a normal, by another value similar to a normal? And how would I translate a normal, by another value similar to a normal?

It won't be long 'till I can do Wii homebrew again.(temporarily)
I'm going to find another 3D format, and write a loader for that. But still, I want answers to the above things still. Everyone, what's your opinion on the .md2 format? I already wrote a loader for that on PC.

I found this. Now, how do I do translation? And would somebody please answer that extraction question?

I have found some information on translation and matrices. Now I need to implement this, and hope it works...

yellowstar wrote:

I have found some information on translation and matrices. Now I need to implement this, and hope it works...

you can roll your own matrix code, but you good also use the hardware. the glRotate and glTranslate functions make use of the hardware.

elhobbs wrote:

yellowstar wrote:

I have found some information on translation and matrices. Now I need to implement this, and hope it works...

you can roll your own matrix code, but you good also use the hardware. the glRotate and glTranslate functions make use of the hardware.

And a lot of the hardware is asynchronous, which is a good thing. Utilizing it efficiently gives you parallel processing passages in your program, where the hardware computes one thing and your software computes something else, until the hardware is done.
Not using the hardware is cycle wasting and we don't have any precious cycles to waste on the NDS! ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

elhobbs wrote:

yellowstar wrote:

I have found some information on translation and matrices. Now I need to implement this, and hope it works...

you can roll your own matrix code, but you good also use the hardware. the glRotate and glTranslate functions make use of the hardware.

This code is only intended for Wii, in an attempt to get this Wiimote model to rotate and move like I said before.
First, the vertices would need normalized. It would most likely be difficult to use GX_Scale*/glScale* to do this, correct? Next the verts would need rotated and translated, then resized back to the original size. Is there any way to do this with hardware?

For doing resizing, which boundary vertex normal to use, would that depend on the quadrant? So if one of the vertices of the model was to the top-left of the origin for x/y/z, the boundary vertex/normal data for the top-left from the orgin for x/y/z, would be used?

EDIT:
Also, how would I calculate the value used for the scaling/multiplication for the resizing? I couldn't used a fixed value, since that would really screw up the model. Right? I think using a fixed value would produce a box.

neither of the posted pieces of code deals with smoothing groups, which is kinda required for proper .3ds replay. I could do some grave-digging to see if I can find the old code I used back in those days for that purpose...

Well, implementing smoothing groups is rather trivial, if you need them at all.

A similar approach to the "meshes in a model" in my (generic) example could be used. ;^)

Alternatively, instead of having fully dublicated vertices (across separate smoothing groups, if effectively using separate meshes for them), the vertex normals could be stored in the primitive ("polygon") structure, as opposed to the vertex structure, which would allow for sharing of vertex positions across adjacent smoothing groups.

I think the latter solution is potentially more memory friendly than the other, as you only have to "move" two (for lines), three, four or whatever amount of normal vectors from the vertex structure to the primitive structure, instead of holding multiple version of the same vertex (at least 6 additional floats for each copy: position + normal).

Another benefit is, that you wouldn't need a primitive normal any more, as you could simply give the structure an attribute that tells you whether to smooth shade or flat shade (or wireframe etc) it, yet still saving bytes (at least worth two floats) in total. If flat shading is needed, only the first normal woulb be taken into account (and computed accordingly beforehand!) That is assuming, you don't use specialized structures for each task. ;^)

Please correct me, if I'm wrong.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

@kusma:
That would be great.

Daivuk gamedev poster wrote:

Or a simpler way if you are going to change format anyway:
Tell your artists to never mirror an object, and if they have to do, attach that object to a non-mirrored one after mirrored it :)

Because when 3D studio mirror an object, it just flips the matrix, not the actually mesh!

And I have seen that problem not only with .3ds
Also by taking the SDK and coding my own exporter.

yellowstar on gamedev wrote:

@Daivuk:
Mirroring could be the problem. I have only tested this with one model, a Wiimote/Wii Remote model. Since the left and right halves are identical, they probably are mirrored. I need to test more models.
All the models I use are either downloaded off Internet, or some bad model I attempted to model.(I'm not so good with modeling...)

A while ago I made a test .3ds, but for some reason, for the texture, all I got was white objects...

Just a short remark: If this is about Wii development, it shouldn't be in "DS development."

Have you double checked your texture loading code?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Uh, yeah. But this happens on every platform I have it running on, so it is a general 3D problem. This loader uses PNGU for loading the png textures. I checked the png I'm using, and it's compatible with this png loader...(I got PNGU running on PC also, not just Wii.)

I actualy didn't mean the image loader. :^D
You really have to check the implementation of your model textures (could be texture assignment, buggy stuff you skip when not loading a texture model etc.). Something is buggy there, but it's hard to tell for me without the source code.
You mind sending me over some small example and test data (working and not working sets)? I might get a look at it. PM me. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Here's the download. Includes a Windows binary, along with the DLLs for libpng and libz. Wiimote and test models are included. By default wiimote.3ds is loaded. In the download, wiimote.3ds is the test model, while the other model is the actual wiimote model. Note that the .3ds code is based on a tutorial, and has yet to be rewritten to be more "yellowstar code" instead of "tutorial code". The file that is written to after the model is loaded, dump.bin, that's a dump of the texture data. The original .obj can be found here.(A Wii binary is not included, as I haven't gotten around to writing that custom Wii Makefile for compiling the PNGU library. The Wii examples don't come with that Makefile. PNGU is meant to be compiled with the rest of the code, instead of a seperate library, since the Makefile for this, is missing. I first wrote that Makefile when I was on vacation, but I forgot about saving that Makefile for transfer onto this computer...)

You can find the original Wiimote .obj here.

Oh, I'll go to bed now (it's NULL o'clock here) and look at it tomorow.
I can't promisse anything, but I'll try to at least find what is messing up your data. :^)
ANd the windows version is just fine. I hope the relevant source files are included aswell. ;^)

Till tomorrow. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

The 3DS Loader files are contained in source and include directories. The Wii code is located in main.cpp in source directory, while PC is located in PCLoader directory, in main.cpp. Models are located in PCLoader/Output/MingW.

Maybe this matrix stuff could be done with hardware. Perhaps I could normalize the vertices, then have the hardware do to the matrix stuff when drawing.

That's what the matrices (and hardware T&L in general) are there for. :^)

I have tried the example and loading the real WiiMote made it really sloooow. Immediate mode rendering, yay! ;^D

I'll take a look at the program later today.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

If I knew how to use Wii Display Lists properly, rendering would be much faster. I know how to use openGL display lists on PC, but my display list code for Wii causes THE fatal Wii/GC crash: The entire screen goes black, with what appears to be stars. Wii Remote/controllers won't do anything. CPU froze. The the entire system freezes. The only way to start over is to use the power button on the Wii. It so easy to crash Wii/GC with GX/Graphics stuff that it's not funny. One tiny mistake, and the whole thing goes down with THE crash.

Once I find the correct way to use Wii Display Lists, the PC version will use display lists also. But, I think the Wii version might already render faster than the PC version does now.

You didn't include all files (libpng), so I can't compile it. I'm having a look at it anyways.

Looks like "void ReadMeshTexCoords(stChunk *Chunk)" might be of interest, but I can't tell.

I guess it's best to switch to using Wavefront Object or Milkshape3D files instead. .3ds is overkill and doesn't pay off.

PS: How does the Wii implementation affect the one for the PC? I haven't programmed for the Wii, yet, but I guess that it doesn't have anything to do with OpenGL on the PC, right?
And building display list in OpenGL is like eating a cake. ;^D
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

silent_code wrote:

I guess it's best to switch to using Wavefront Object or Milkshape3D files instead. .3ds is overkill and doesn't pay off.

PS: How does the Wii implementation affect the one for the PC? I haven't programmed for the Wii, yet, but I guess that it doesn't have anything to do with OpenGL on the PC, right?

I'm not using .obj. This Wiimote model, in .obj format, it's ~2 MB. While the same model in .3ds, it's only ~ 700 KB. I can't use Milkshape directly. Is there any Milkshape import/export plugins for Blender?(Is using the native format of a "non-free" program legal, in other programs? Like using a completely different program for the format, not the intended software at all.)(But I'd have to learn Blender all over again...)

I suppose I could use display lists on PC... I'd prefer my Wii lists to work, but implementing GL lists is easy. The implementations don't really affect the other. Other than the glitch both of them share.

AfaIk, it is legal and current verions of blender com with MS3D support build in. ... Chumbalum Soft is not Adobe, you know. Mete supplies source code to handle the format and encourages it's use. :^D

Damn I have missed my 1337th post! ;^D
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

silent_code wrote:

AfaIk, it is legal and current verions of blender com with MS3D support build in. ... Chumbalum Soft is not Adobe, you know. Mete supplies source code to handle the format and encourages it's use. :^D

What version? I have 2.46, build 2008-05-18 21:59:29. Was it updated already?

Me too. It's under "Import." :^D
Damn, I have just realized, that there is no exporter... bugger. But there might be some script or plugin around, too.

Sorry for the confusion.

(I have a MS3D license, so that's all not a problem for me...)

Why do you care so much about how big the .obj file gets? The model in memory will be much smaller and after all, it's only for testing. Also, small models that fit the NDS won't be too hughe.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Apparently I didn't see the Milkshape import button the first time I tried to find it. No export though. )-:

Quote:

Why do you care so much about how big the .obj file gets?

Dial-Up. If I release any 3D Wii homebrew, I really don't want to wait on a big upload just because the models are in a text format...(But when I'm doing Wii homebrew, I would usually have access to DSL, however...)

Text files compress quite well. I get around 25% of the original file size. For NDS models (no animation) I get just a couple of kB. But then, I know the dial-up problem very well. :^(

The best thing you could do, is to write a simple converter, that loads some widely used format (.obj) and saves it in some custom, compact, binary form that's easy to use.

PS: Check this out. If you know how to get it to work with 2.4.6, it may come in handy.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

I'd like to use animation, too.(That script seems to be not working with animation, like the posters said.)
ATM, I don't know how to use custom Python scripts.

This Wiimote model, is was originally modeled in Max. Then somebody converted it to .obj. And lastly, I converted the .obj to .3ds. If I were to load/convert the Wiimote .obj, wouldn't this same glitch still exist?

Keep in mind that 3ds files have several issues... max 2^16 vertices per mesh, the lack of support for both correct normals and texture coordinates at the same time, just to mention a few.

I said I'd look for the sources I had for generating the normals from the smoothing groups, but I can't find it, sorry.

I tried using this Wiimote .obj with a Wii .obj loader,(I didn't write that)
and it crashed. So ATM, I don't know if the model displays correctly, or not, in .obj.

If it loads into a modelling program, then it's ok.
The .obj viewer probably crashed because it's been buggy anyways.
Both models (the test and WiiMote) display correctly in Cinema4D (loaded from .3ds), so it's not the models.
.obj is very easy to load and I can't imagine how it could not work. You should look for better examples, I guess. ;^)

EDIT: Maybe this will help. Or better (Windows, the other one is Mac) this here... only talking about the loader, the rest is... worse.

Again, I think the uv coordinates are wrong! Check that! (Simple quad "model" for testing should do it. Unfortunately this one doesn't work - it crashes your program.)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Both models display fine in Anim8or.(Wiimote is fine with Blender)
However, with this test model of mine, multiple vertices use the same tex choord. Could that be a problem? How would I redo the tex choords with RoadKill? I'm thinking of testing this Wiimote model with that MD2 loader I made a long while ago...(But the the exported MD2 will probably be invisible because of Blender...)
I tried normalizing the Blender Wiimote's vertices, then scaling the model by 10.0f, and even 100.0f, and I still don't see anything.

What software did you use to make this test model with? Cinema4D?

EDIT:
That Windows download doesn't handle textures... And this glitch so far has only appeared with models with textures.

I tried chopping the left and right halves of the Wiimote model, /w Anim8or, then mirroring the other half. And then joining the two halves together, then exporting to .3ds. Both exported models didn't fix anything.

Apparently I forgot to re-enable the code which does the vertex normalizing... The test model of mine, part of the box is missing, and there's some triangles flying around that might be those missing triangles. And there's multiple objects in this test model, but the other objects aren't displayed...

EDIT:
O_O The pimary/main .3ds chunk in your test .3ds silent... The length is way different than the filesize. When my code detects that the filesize and main chunk length is different, it flips endians for everything. Which will cause major problems when endian flipping isn't needed. I tried fixing this with a hex editor, but my program is still crashing... When running as normal, the crash happens. But when debugging, all it says that it failed to load the .3ds file. That error message doesn't help at all, and it's not even returning zero for failure... Or at least not supposed to...

yellowstar wrote:

(Is using the native format of a "non-free" program legal, in other programs? Like using a completely different program for the format, not the intended software at all.)

Is using Microsoft Word .doc legal, in OpenOffice.org Writer?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Yes, the "model" was made in C4D (which never had any problems with .3ds) and after testing the directly exported .3ds, your program crashed. Then I tried to load it into MS3D (worked flawlessly, as usual) and export it again. Yet, the program crashed again.

I am certain I saw some texture on the models... what do you mean by " (it) doesn't handle textures" then?

Isn't the endianness of .3ds specified? That's the benefit of text based formats (like .md5 ;^D ) - bytes are bytes are bytes are... :^D (except when using WCHAR text ;^p )

And you really need to test simple models first. Really.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

I tested this with a simple cube, and there wasn't any problems... silent, could you try modeling a simple cube and try to load the .3ds with my loader?

Quote:

I am certain I saw some texture on the models... what do you mean by " (it) doesn't handle textures" then?

The link you posted for the .obj loader on Windows. The included tree model doesn't have a texture. Does the program handles textures, but the demo doesn't use them? AFAIK, .3ds doesn't have an endian field anywhere in the format.

Another thing: That exported Blender model, it still don't show up now that the resize code is enabled.(That's in the same code that handles normals)

yellowstar wrote:

AFAIK, .3ds doesn't have an endian field anywhere in the format.

It doesn't need it. Good old Autodesk 3DStudio only existed for MSDOS, and is therefore little endian by nature.

I thought it had to do with reasons like that. One of the reasons I thought of was that 3DStudio, and .3ds, could only be used on systems with one kind of endian.(If endians even existed back then, that is.)

yellowstar wrote:

If endians even existed back then, that is.

It sure did.

Sure like hell. :^) Motorola 68k, baby! (Very popular big-endian processor family, probably TEH 1X [unix] CPUz back then. Apple, Amiga, you name it, ... errr... it had a 68x :?D)
:^d Yummy!

I will make a textured cube and export it, then up it to my server.

I have inspected the example program and nearly cried... how do they teach programming these days? The guy loads the model each damn FRAME! ARRRR!!!!

Yeah... But I bet NeHe ect. have better examples for .obj loaders. The format is beatifully simple, yet powerful (supports free form surfaces etc).

All you need is a simple parser that reads in Objects, vertices, UVs, Faces, Normals and maybe even Smoothing groups. Works flawlessly most of the time (that means, if freeform surfaces are not used).
The drawback is, that it lacks animation.

Milkshape is very inexpensive and it helps me a lot. Might be worth the few bucks. (I actually had to save for that - which indicates how much money I had at the time: none.) It also comes with a nice little plugin API. If you're on unix, I guess it will work with wine under linux, but I don't know.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

NeHe has tutorials on loading a custom text format, and Milkshape models, but that's all there is for model loading on NeHe.

I don't even have a job... And I rather not spend money that took a long time to save to get enough, on stuff that I might hardly ever use...

The latest version of Caligari Truespace, now 7.6, has been released as a free download to the public, along with the full PDF manual and video tutorials.

couldn't get much more convenient than that

Stop spamming!
On a personal side note: I find even blender easier to use than TS... :^\
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

*groan* Another one?! Ugh... Yet another "free" 3D software program,(previously commercial)
that requires you to register for an account, with your address and phone number. I'm so not doing that.(I really dislike these "free" programs...)
Wonder if it's legal to redistribute these "free" programs...

spamming!?
you don't honestly believe that?

my goodness you whine about affordablity then whine about free stuff?
Boy you guys sure are hardcases, more intend on providing each other with much needed therapy more than actually finding any realistic solutions. I'll let you be.. and delete.

Cheers

ps. Nothing wrong with therapy: personally i prefer 3dsMax ;)

@ anon:

And what's your point, mister?

We don't advertise anything in that way in this forum. Your post does not help anyone. If you wrote "Well, using the recently freely released TS 7.x might sovle problem XYZ", it wouldn't be a blatant spam ad!

Plus we often find post by people that only post once... and it's spam.

Is that why we "need Therapy?" I haven't actually listened to them, so I might try just now. Thanks for your thoughtful help. :^p

Your answer seems a little bit harsh. You should give it a thought.

And why would you insult people? No need for personal attacks.

PS: If downloading a free software results in unwanted phone calss and mail (both physical and digital) his point is totally valid. Plus, it's TS!? I prefer C4D or anything else (maybe not Amapi3D).
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Last edited by silent_code on Sat Jul 26, 2008 10:21 am; edited 2 times in total

Sometimes people will say something like:

<shameless plug>
You could always use My Project V1.23. It can do X, Y and Z.
</shameless plug>

-Brendan

EDIT: An active link was added for illustrative purposes. Google was chosen because it is not objectionable and it can answer all of your questions (although not necessarily well). Clearly I did not make google.

Last edited by sgeos on Sat Jul 26, 2008 10:40 am; edited 1 time in total

Dude, you made Google? Wow... can I havz teh sourz codez?
Or are you a spammer advertising that devil program????

...

Nah, just kidding. Greets. :^D
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

So I guess the OP was resolved a while ago:

Q. "3ds, and screwed faces"

A. The 3ds faces aren't screwed, my program just doesn't work properly yet.

Pretty much, yes.

Although I suggested using another format, which is easier to use, but there doesn't seem to be a good solution for yellowstar, yet.

@ yellowstar: I haven't done the textured box test, yet, but I will eventually. ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Yesterday I attempted to convert this large Wiimote model to .md2, and that failed... Blender/.md2 exporter froze. And now for some reason, the Wii port of this loader is crashing with the "stars" crash.
For formats with animation, .md3 and .x are candidates. But I can't code loaders for those ATM.(Vacation; Coding another loader will most likely wipe out my whole vacation this time)

So, as promissed, I made a textured cube (instead of the UV mapped 2 triangle quadrial) and saved it with Cinema4D's 3D Studio R4 (OOOOld) exporter.

Works fine... not really, but well, at least it doesn't crash the program. ;^)
I guess that's because this time, it's a closed mesh.

Now, from what I can tell, the UVs are totally mixed up. Either they aren't loaded propperly or something overwrites them.
As you have commented out the normal calculation (DON'T DO IT PER FRAME!), it's not that, what corrupts them.

I'm sorry I can't take a closer look at your implementation. :^(

Here's the cube (3kB) (yeah, like you couldn't make your own ;^D ), including my test texture.

As you will see, there are UVs for every primitive, but all are distorted and some are mangled to the point, where only two or three texels are used, instead of tens or even hundrets.

I hope this helps.

Greetings!
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

I'm not calculating normals every frame... When that's uncommented, it checks if it already did normals calculation, by checking if the normals dynamically allocated array pointer is NULL. If it's NULL, it continues, otherwise, normals calculation isn't done.

I asked you to make a cube because that other model you made crashed my program.

I know why you asked me to make the cube... :^) I was just suggesting why it would crash the program.
The reason I uploaded it, was to give you a file that was porbably created by a different implementation that what you use to create .3ds files. You know, for testing purposes and analyzing. ;^)

@ any gimp that read this and laughed: ... Yeah, analyzing... Big deal.

Well, I know this is just a test application, but even if you don't calculate normals every frame, you still don't want to have that unnecessary function call there. You probably know that: Calls are expensive, especially when they do nothing. ;^D

Yah, anyways. So, did you make any progress?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

Sorry it took a while to reply - I was on vacation previously. I'm getting really tired of .3ds... I just want to switch to some other format... But I can't do that until that Blender resizing issue is fixed... That cube is really screwed up... Doesn't even look like a cube displayed with my loader, IMO. I can see the original glitch with back faces being drawn on top of the front faces with this model. I don't know how to fix that UV glitch... In particular when that's a .3ds glitch...

gbadev.org forum archive

DS development > .3ds, and screwed faces

#160290 - yellowstar - Sun Jul 13, 2008 7:14 pm

#160295 - Holland - Sun Jul 13, 2008 8:28 pm

#160296 - nanou - Sun Jul 13, 2008 8:29 pm

#160299 - yellowstar - Sun Jul 13, 2008 8:37 pm

#160300 - Holland - Sun Jul 13, 2008 8:40 pm

#160302 - zeruda - Sun Jul 13, 2008 8:51 pm

#160303 - yellowstar - Sun Jul 13, 2008 8:58 pm

#160305 - silent_code - Sun Jul 13, 2008 9:06 pm

#160309 - yellowstar - Sun Jul 13, 2008 9:30 pm

#160310 - silent_code - Sun Jul 13, 2008 9:50 pm

#160311 - yellowstar - Sun Jul 13, 2008 10:16 pm

#160312 - yellowstar - Sun Jul 13, 2008 10:56 pm

#160318 - TwentySeven - Mon Jul 14, 2008 12:18 am

#160325 - yellowstar - Mon Jul 14, 2008 2:38 am

#160328 - yellowstar - Mon Jul 14, 2008 2:53 am

#160335 - TwentySeven - Mon Jul 14, 2008 3:44 am

#160352 - JYC376 - Mon Jul 14, 2008 2:40 pm

#160354 - silent_code - Mon Jul 14, 2008 2:51 pm

#160357 - JYC376 - Mon Jul 14, 2008 3:17 pm

#160366 - silent_code - Mon Jul 14, 2008 4:24 pm

#160397 - yellowstar - Tue Jul 15, 2008 12:10 am

#160398 - silent_code - Tue Jul 15, 2008 12:28 am

#160410 - JYC376 - Tue Jul 15, 2008 10:16 am

#160414 - Maxxie - Tue Jul 15, 2008 11:11 am

#160417 - silent_code - Tue Jul 15, 2008 12:25 pm

#160429 - yellowstar - Tue Jul 15, 2008 7:07 pm

#160434 - silent_code - Tue Jul 15, 2008 8:07 pm

#160437 - yellowstar - Tue Jul 15, 2008 9:52 pm

#160439 - chuckstudios - Tue Jul 15, 2008 10:00 pm

#160440 - silent_code - Tue Jul 15, 2008 10:05 pm

#160441 - Maxxie - Tue Jul 15, 2008 10:13 pm

#160443 - TwentySeven - Wed Jul 16, 2008 12:29 am

#160444 - yellowstar - Wed Jul 16, 2008 12:38 am

#160451 - yellowstar - Wed Jul 16, 2008 2:41 am

#160459 - silent_code - Wed Jul 16, 2008 9:00 am

#160462 - Maxxie - Wed Jul 16, 2008 9:23 am

#160463 - silent_code - Wed Jul 16, 2008 10:43 am

#160464 - a128 - Wed Jul 16, 2008 11:32 am

#160474 - yellowstar - Wed Jul 16, 2008 5:51 pm

#160477 - silent_code - Wed Jul 16, 2008 6:48 pm

#160481 - yellowstar - Wed Jul 16, 2008 7:45 pm

#160491 - silent_code - Wed Jul 16, 2008 8:45 pm

#160542 - yellowstar - Thu Jul 17, 2008 3:37 pm

#160543 - Maxxie - Thu Jul 17, 2008 3:55 pm

#160547 - yellowstar - Thu Jul 17, 2008 4:29 pm

#160553 - Maxxie - Thu Jul 17, 2008 6:20 pm

#160554 - yellowstar - Thu Jul 17, 2008 6:27 pm

#160561 - yellowstar - Thu Jul 17, 2008 8:11 pm

#160568 - elhobbs - Thu Jul 17, 2008 9:04 pm

#160575 - silent_code - Thu Jul 17, 2008 9:58 pm

#160635 - yellowstar - Fri Jul 18, 2008 11:47 pm

#160669 - yellowstar - Sat Jul 19, 2008 10:56 pm

#160670 - yellowstar - Sat Jul 19, 2008 11:15 pm

#160676 - elhobbs - Sun Jul 20, 2008 1:50 am

#160684 - silent_code - Sun Jul 20, 2008 9:46 am

#160713 - yellowstar - Mon Jul 21, 2008 12:18 am

#160732 - kusma - Mon Jul 21, 2008 8:12 am

#160738 - silent_code - Mon Jul 21, 2008 10:44 am

#160763 - yellowstar - Mon Jul 21, 2008 4:44 pm

#160766 - silent_code - Mon Jul 21, 2008 4:59 pm

#160800 - yellowstar - Tue Jul 22, 2008 6:31 pm

#160808 - silent_code - Tue Jul 22, 2008 9:53 pm

#160811 - yellowstar - Tue Jul 22, 2008 10:54 pm

#160814 - silent_code - Tue Jul 22, 2008 11:04 pm

#160815 - yellowstar - Tue Jul 22, 2008 11:08 pm

#160828 - yellowstar - Wed Jul 23, 2008 3:09 am

#160843 - silent_code - Wed Jul 23, 2008 11:58 am

#160851 - yellowstar - Wed Jul 23, 2008 5:53 pm

#160869 - silent_code - Wed Jul 23, 2008 9:07 pm

#160871 - yellowstar - Wed Jul 23, 2008 9:37 pm

#160872 - silent_code - Wed Jul 23, 2008 9:54 pm

#160873 - yellowstar - Wed Jul 23, 2008 10:08 pm

#160874 - silent_code - Wed Jul 23, 2008 10:34 pm

#160876 - yellowstar - Wed Jul 23, 2008 10:46 pm

#160879 - silent_code - Wed Jul 23, 2008 11:21 pm

#160883 - yellowstar - Wed Jul 23, 2008 11:41 pm

#160885 - kusma - Wed Jul 23, 2008 11:47 pm

#160886 - yellowstar - Wed Jul 23, 2008 11:55 pm