Deep Exploration, OpenGL, and 3d models

well I have just aquired an application that was suggested to me by a friend who is in the computer gaming industry called Deep Exploration.

This application converts a 3d model of various formats to any one of other various formats.

I have been wondering about the usage of 3d models in OpenGL code lately, and so I aquired this program in order to help convert files to a proper format so that I might be able to use them.

All of my 3d models were originally in .3ds format (3DS Max mesh), but I did not know how to use a 3ds mesh in OpenGL, so I decided to convert it to OpenGL code using Deep Exploration.

Take into account the model I am converting contains about 9500 vertices and 18000 triangles.

The resultant cpp file was 15000 lines of code in length, made up of almost purely data for those vertices and faces.

(Obviously it put them in display lists).

What do you think of this method? Do you think it would be more efficient to just find out a method of loading the .3ds mesh into my program instead of converting it into a OpenGL cpp code file?

Or do you think it would take the same amount of data and processing power either way I go?

I'm not sure whether I really want to try implementing this model as a cpp file when the file is over 15000 lines long of data....but then again....if I learned the .3ds format and created my own loading procedures to lead the .3ds mesh, wouldnt it take just the same amount of data, or what?

How much do you think it would affect my fps rate? (my current rate is about 60 fps with my 3d terrain generator I have created so far).

I am not even really sure what in the hell you are talking about. It sounds like you are just writing a program that makes it so you can hard code the vertices into a source file. If that's what you are doing, that is, imho, dumb. I dont' know what it would do speed wise, seeing as how you are doing the project, why don't you use the timeGetTime or GetTickCount functions to determine which is faster...instead of leaving us who haven't done it to speculate. That would never be used in a 'real' game considering the modding community.

EDIT: now that I think of it I cannot think of a single good thing to come out of your little project thingamabob. Speed isn't really an issue once the model itself is in memory (assuming a reasonable amount of vertices being rendering). I mean, you either store the model in the binary which has to ultimately be loaded into memory, or you have to store the model in a .3ds file which also has to ultimately be loaded in the memory. And as I said before, the actual drawing process shouldn't be changed too much, things should be fast enough loading from a file.

the main difference here is that you are hard coding the model into the program (big ass .exe) rather than reading it from a file. (big ass .3ds), i dont see any obvious advantages here.

>
What do you think of this method? Do you think it would be more efficient to just find out a method of loading the .3ds mesh into my program instead of converting it into a OpenGL cpp code file?
Or do you think it would take the same amount of data and processing power either way I go?
<

It will peobably be the same, only speed change might come about from exe size bloating? How many display-lists does it use for the model? And how does it store the data?

A downside is the loss of being able to modify the model without a recompile.

Quote:

---

A downside is the loss of being able to modify the model without a recompile.

---

I would say that is a pretty big loss,I mean, can you imagine having to reinput the entire code each time you make a change to your model?

can you imagine having to compile 20,000 lines of code (assuming 5,000+ for the code) if you want to change one vertex? Even if you lack the time/patience/motivation/knowledge/skill to program a 3DS loader yourself, there are a ton of them out there that will load your model into the OpenGL stucts for you. You won't learn jack doing it like that, but it's still better than hard coding the model.

If you place that data directly in the program, won't it be placed on the stack rather than the heap. I'm no expert on this, but isn't the stack more limited than the heap?

Quote:

---

Originally posted by Magos
If you place that data directly in the program, won't it be placed on the stack rather than the heap. I'm no expert on this, but isn't the stack more limited than the heap?

---

the stack certainly is different from the heap, but not neccesarily more limited
in general , the stack starts at one end of memory, and the heap at the other, they grow 'towards' each other and thus have the same amount of available space. here is a simple way of looking at memory..

Code:

---

----------------------------------
          Kernel space

----------------------------------
    stack starts here 
    and grows down 







heap starts here and 
grows up                   
----------------------------------

---

Quote:

---

Even if you lack the time/patience/motivation/knowledge/skill to program a 3DS loader yourself, there are a ton of them out there that will load your model into the OpenGL stucts for you

---

heh heh...thats what you think....

now that you have said that, go out and find one. trust me it isnt easy. and its even harder to find a tutorial on how to use one that you may happen to find, or how to make one yourself, etc.

I have found a total of two things:

Nehe's Model Loading tutorial - however this loads Milkshape 3d models...I dont have Milkshape 3d and none of my models are in that format. They are all in .3ds format. And Deep Exploration does not have the capability to convert from .3ds to any Milkshape 3d format.

lib3ds - this is a 3ds model loader....supposedly one of the only ones out there...and definitely the only one I have found. However it is incredibly poorly documented, so I am prowling around in the dark hoping that I might be able to get it to work with my program.

You know of any others? You know of any ones that are documented well? You know of any tutorials that are good? Please...do tell....

Scroll down a bit on this one, it's there
http://www.home.no/apron/english/apron.htm?tut_gl

There is one here as well
http://ironduke.cs.gsu.edu/gso_class..._resources.htm

Yup, it's near the bottom
http://webster.fhs-hagenberg.ac.at/s...asp5_20012002/

Not sure if this one is OpenGL, but I believe it is
http://www.flipcode.com/cotd/COTD-3DSLoad.shtml

Scroll down a bit
http://www.gametutorials.com/Tutoria...OpenGL_Pg4.htm

At the bottom
http://www.sulaco.co.za/nitrogen/projects.htm

Loading 3DS in general, really simple
http://www.levp.de/3d/index.html

I think that's enough, something there should be useful...my source...Google and about 5 minutes total.

Quote:

---

Originally posted by Perspective
the stack certainly is different from the heap, but not neccesarily more limited
in general , the stack starts at one end of memory, and the heap at the other, they grow 'towards' each other and thus have the same amount of available space. here is a simple way of looking at memory..

---

So every program have their own stack and heap? I thought that the heap had access to all available RAM, not just a limited space in your program. Or is the heap simply a list of adresses to some other location in memory?

I believe that it works as thus, but I am not positive...

Every program has access to the stack.

Every program is allocated a chunk of the heap...I think it might be allocated in chunks of 1 mb or something like that, so you probably end up with some extra unless your program is exactly on the barrier. Anyway, if you make a fat, bloated program that contains all of its data in the .exe, then you'll be given a huge chunk in the heap, instead of a small one...so, if the heap as a whole takes up more room, I guess there would be less room for the stack. That's my understanding, at least.

Quote:

---

Originally posted by Magos
So every program have their own stack and heap? I thought that the heap had access to all available RAM, not just a limited space in your program. Or is the heap simply a list of adresses to some other location in memory?

---

each program will have a certain amount of the heap allocated for its use, not all of it. when your programs heap gets full, it can request more heap space from the OS. it depends on the memory manager.

much of the RAM is off limits for apps, particularly kernel space and registers stored in memory (yes, some registers are stored in memory instead of actual registers). this does not necessarily mean your app cannot access these places, but overwriting system memory to store your own data is usually a bad idea :)

I thought the heap was just all extra RAM that isn't being used by anything, its just leftover fat. Once a variable has had space allocated for it, it technically isn't on the heap because it is now on the stack. I also thought that when the stack grows, the heap shrinks, and vice versa. I can't double check my books cuz im not at home, but im pretty sure that's what they said. Perspective your diagram doesn't make sense, because it seems there would be 'holes' in the memory layout between the stack and heap space.

Quote:

---

I thought the heap was just all extra RAM that isn't being used by anything, its just leftover fat.

---

that is also what I recall being taught by my Comp Sci teachers.

What I have been taught is that the stack is a set amount of memory allocated to each program....a relatively small portion of the memory at that...I have also been taught that if you want to exceed the memory given to you in the stack, you allocate memory in the heap using pointers, and that the heap is memory not being used by any program at the current time. Thats what they teach you in AP Comp Sci....correct me if I am wrong....

Are variables allocated on the heap also pushed onto the stack? The image I have in my mind is that whenever you allocate memory on the heap the stack 'eats' a portion of the heap.

H = Heap
S = Stack
Total memory before allocation:
5 S's, 5H's
SSSSSHHHHH

Total memory after allocation:
6 S's, 4H's
SSSSSSHHHH

Stacks eating heaps...
what the hell is the world coming to?

heap

1. <programming> An area of memory used for dynamic memory
allocation where blocks of memory are allocated and freed in
an arbitrary order and the pattern of allocation and size of
blocks is not known until run time. Typically, a program
has one heap which it may use for several different purposes.

Heap is required by languages in which functions can return
arbitrary data structures or functions with free variables
(see closure). In {C} functions malloc and free provide
access to the heap.

Contrast stack. See also dangling pointer.

Source: The Free On-line Dictionary of Computing, © 1993-2003 Denis Howe

[edit]
In certain programming languages including C and Pascal, a heap is an area of pre-reserved computer main storage (memory) that a program process can use to store data in some variable amount that won't be known until the program is running. For example, a program may accept different amounts of input from one or more users for processing and then do the processing on all the input data at once. Having a certain amount of heap storage already obtained from the operating system makes it easier for the process to manage storage and is generally faster than asking the operating system for storage every time it's needed. The process manages its allocated heap by requesting a "chunk" of the heap (called a heap block) when needed, returning the blocks when no longer needed, and doing occasional "garbage collecting," which makes blocks available that are no longer being used and also reorganizes the available space in the heap so that it isn't being wasted in small unused pieces.
The term is apparently inspired by another term, stack. A stack is similar to a heap except that the blocks are taken out of storage in a certain order and returned in the same way. In Pascal, a subheap is a portion of a heap that is treated like a stack.

-source: http://whatis.techtarget.com/definit...212239,00.html
[/edit]

here, its kind of hard to explain in words but my diagram is correct. i know this is an apple site but it has the best diagrams i could find.

http://developer.apple.com/techpubs/...oMemMgmt.4.htm

the definitions given above by DavidP are correct.

>Are variables allocated on the heap also pushed onto the stack?

no, objects dynamically allocated are stored in the heap. the pointer to the object is the local variable stored on the stack.

ill try one more ascii memory map...

Code:

---


[c++]
object* obj = new object("blah");
[/c++]

meanwhile, in memory....
------------------------------------------

Kernel space
------------------------------------------
Stack: variable 'obj' is stored here (the pointer)








HEAP: the actual object returned by new
          and pointed to by 'obj' is stored here.
---------------------------------------------

---