Hi Fred!
As stated in a pm, a DisplayMesh command like the DisplaySprite command is needed! For example in my game (patternbased) i have to copy a lot meshes (which is very slow) during the game. It would be faster and easier if I could load the object once at the beginning of the programm and can reuse it as often as I wish using a DisplayMesh command.
For example I want to use a 3D-Font to display messages and lot's of other stuff. Each time I change the text I can load or copy a lot of meshes. Or when I want to code a meteorfield or use particles I have to load or copy 327 objects with the same mesh-definitions and the same textures!
Please reconsider your approach in displaying meshes. At the moment I coded my game with a few workarounds, like displaying unused objects behind the camera or copying only the changes to the playfield.
I hope to present to you a playable version in a few days, my work holds me back from doing more!
Yours sincerely
DisplayMesh
-
THCM
- Enthusiast
- Posts: 276
- Joined: Fri Apr 25, 2003 5:06 pm
- Location: Gummersbach - Germany
- Contact:
DisplayMesh
The Human Code Machine / Masters' Design Group
Yes, I'm still thinking about it. Actually, I've 2 choices:
1) Keep the current system, and simply add HideMesh(#Mesh, Hide/Show)
2) Add a DisplayMesh(#Mesh, x, y, z [Mode [, Blending]]) and all the coordinates system will be handled by the PB program, not by OGRE (so no more need for GetMeshX(), GetMeshY(), GetMeshZ(), MeshLocate() and MeshMove()
The second point makes the Mesh lib behave exactly like the Sprite and other 2D lib, which is more coherent. On a plus side, it reduces the instruction set and will make all the access to the object coordinates mush faster, as no GetXX are involved. So by default all meshes will be made invisible and only the meshes which use DisplayMesh() will be displayed.
What do you think its the best way ?
1) Keep the current system, and simply add HideMesh(#Mesh, Hide/Show)
2) Add a DisplayMesh(#Mesh, x, y, z [Mode [, Blending]]) and all the coordinates system will be handled by the PB program, not by OGRE (so no more need for GetMeshX(), GetMeshY(), GetMeshZ(), MeshLocate() and MeshMove()
The second point makes the Mesh lib behave exactly like the Sprite and other 2D lib, which is more coherent. On a plus side, it reduces the instruction set and will make all the access to the object coordinates mush faster, as no GetXX are involved. So by default all meshes will be made invisible and only the meshes which use DisplayMesh() will be displayed.
What do you think its the best way ?
-
THCM
- Enthusiast
- Posts: 276
- Joined: Fri Apr 25, 2003 5:06 pm
- Location: Gummersbach - Germany
- Contact:
Fred I love you! 
Don't take this to serious....
In my opinion choice no. 1 would be easier to implement, but it's not as flexible as the second one.
The second choice seems to be more flexible, but I'm currently rethinking some more options like: orientation, translation etc.
Another approach (my favourite so far) would be to separate meshes, texture etc. from objects.
I don't know how Ogre works internally, but I would guess they use some kind of a display list. So why not split objects and meshes:
Objects only are a container with a mesh, one or more textures, a position in space, a rotation, a size , color, and a few more flags (visibile, type of lightning, type of shading, gouroud, transparency etc.).
A 3d Program could look like this:
1. Load all my meshes, textures, bsp, terrain etc. into the memory without displaying them
2. Define an Object and mark it visible to set it onto the displaylist
3. Start3D Output: all objects on the displaylist will be shown with all their modifications
4. Stop3D Output
3. Rotate, Move, Hide the Object, check for collisions etc., change flags
4. Remove the object from the list or define new ones
5. Goto Point 3
When I don't change anything on the list, everything will be shown as the frame before (like it's done now).
With this approach all the objects are handled by Ogre and i can modify the visible and the non-visible objects.
I can reuse meshes lot's of times for diffrent objects without copying etc.
I can use one texture for diffrent objects (materials, bumps can be reused for lot's of objects!)
An object holds the information of the mesh and the texture, the position in space, the orientation, the size etc.
Please consider these thoughts in your modifications!
Perhaps there are better possibilities and I don't know how Ogre works internally.
So what do you think, Fred?
Don't take this to serious....
In my opinion choice no. 1 would be easier to implement, but it's not as flexible as the second one.
The second choice seems to be more flexible, but I'm currently rethinking some more options like: orientation, translation etc.
Another approach (my favourite so far) would be to separate meshes, texture etc. from objects.
I don't know how Ogre works internally, but I would guess they use some kind of a display list. So why not split objects and meshes:
Objects only are a container with a mesh, one or more textures, a position in space, a rotation, a size , color, and a few more flags (visibile, type of lightning, type of shading, gouroud, transparency etc.).
A 3d Program could look like this:
1. Load all my meshes, textures, bsp, terrain etc. into the memory without displaying them
2. Define an Object and mark it visible to set it onto the displaylist
3. Start3D Output: all objects on the displaylist will be shown with all their modifications
4. Stop3D Output
3. Rotate, Move, Hide the Object, check for collisions etc., change flags
4. Remove the object from the list or define new ones
5. Goto Point 3
When I don't change anything on the list, everything will be shown as the frame before (like it's done now).
With this approach all the objects are handled by Ogre and i can modify the visible and the non-visible objects.
I can reuse meshes lot's of times for diffrent objects without copying etc.
I can use one texture for diffrent objects (materials, bumps can be reused for lot's of objects!)
An object holds the information of the mesh and the texture, the position in space, the orientation, the size etc.
Please consider these thoughts in your modifications!
Perhaps there are better possibilities and I don't know how Ogre works internally.
So what do you think, Fred?
The Human Code Machine / Masters' Design Group
I prefer the second choice Fred:
2) Add a DisplayMesh(#Mesh, x, y, z [Mode [, Blending]]) and all the coordinates system will be handled by the PB program, not by OGRE (so no more need for GetMeshX(), GetMeshY(), GetMeshZ(), MeshLocate() and MeshMove()
P.S. will the next version (3.70) add anything new to the 3D command set?
2) Add a DisplayMesh(#Mesh, x, y, z [Mode [, Blending]]) and all the coordinates system will be handled by the PB program, not by OGRE (so no more need for GetMeshX(), GetMeshY(), GetMeshZ(), MeshLocate() and MeshMove()
P.S. will the next version (3.70) add anything new to the 3D command set?
--Kale
-
THCM
- Enthusiast
- Posts: 276
- Joined: Fri Apr 25, 2003 5:06 pm
- Location: Gummersbach - Germany
- Contact:
Hi Kale!
At the moment there's no need for commands like GetMeshX(), GetMeshY(), GetMeshZ() and MeshMove()! You can handle these with your program. The only command you need is MeshLocate()!
If Fred choses the second approach, how should Fred handle the orientation of a mesh? The DisplayMesh command would need 3 more variables for the rotation of the mesh! And what about mesh-animation?
I think more useful is the approach i explained in an earlier post. To split 3D-Objects into smaller components (meshes, textures, modifiers etc.) so the program has more control over the objects.
If you want to code a Quake-like game, the current system is ok. You have a bsp-level and perhaps a few objects on the screen. But for other games like racing games, shoot'em ups, jump'n'run etc. where you have lots of objects of the same type my approach would be much easier!
If you want to code a game with lot's of diffrent enemies, where only a few diffrences (color, texture, size) exits like in a mmorpg, everything has to be loaded a few times into the computers memory!
So my (3rd) approach is more flexible in my eyes! So, what Do you think about it Fred? Is Ogre capable of doing it?
At the moment there's no need for commands like GetMeshX(), GetMeshY(), GetMeshZ() and MeshMove()! You can handle these with your program. The only command you need is MeshLocate()!
If Fred choses the second approach, how should Fred handle the orientation of a mesh? The DisplayMesh command would need 3 more variables for the rotation of the mesh! And what about mesh-animation?
I think more useful is the approach i explained in an earlier post. To split 3D-Objects into smaller components (meshes, textures, modifiers etc.) so the program has more control over the objects.
If you want to code a Quake-like game, the current system is ok. You have a bsp-level and perhaps a few objects on the screen. But for other games like racing games, shoot'em ups, jump'n'run etc. where you have lots of objects of the same type my approach would be much easier!
If you want to code a game with lot's of diffrent enemies, where only a few diffrences (color, texture, size) exits like in a mmorpg, everything has to be loaded a few times into the computers memory!
So my (3rd) approach is more flexible in my eyes! So, what Do you think about it Fred? Is Ogre capable of doing it?
The Human Code Machine / Masters' Design Group
Actually, each mesh use the texture you specify, so several mesh can use the same texture. When you copy a mesh object, you don't really copy the mesh inside, but you just have another separate object which its own coordinates, rotation etc.. which use the same mesh. To sum up, actually you can (in the current version):
- Use the same texture for every mesh
- Meshes are smart objects which replicate only when needed (or use the same shared resource else)
- Each objects has their own attributes
So my point was just about the handling of the display. Actually, with the 2D engine, you have to handle the x,y position by yourself so you don't have GetSpriteX() and such command. Additionnaly, a sprite is displayed only if the DisplaySprite() command is used. So is it realalistic to apply this to the 3D engine ? It works a bit different than other one but it has some advantages like the speed of x,y,z access. So like the sprites, the mesh will be made invisible automatically at each frame. Does it make sense ? So even MeshLocate() will be removed.
All objects can be easily handled with linkedlist(). Here is a pseudo code:
All suggestions are welcome. This way seems more natural to me, as it's exactly the same way than the sprites works. All other stuffs like the Rotation, Lightning, etc.. will be properties of the object, and could be set with Set/Get like commands
- Use the same texture for every mesh
- Meshes are smart objects which replicate only when needed (or use the same shared resource else)
- Each objects has their own attributes
So my point was just about the handling of the display. Actually, with the 2D engine, you have to handle the x,y position by yourself so you don't have GetSpriteX() and such command. Additionnaly, a sprite is displayed only if the DisplaySprite() command is used. So is it realalistic to apply this to the 3D engine ? It works a bit different than other one but it has some advantages like the speed of x,y,z access. So like the sprites, the mesh will be made invisible automatically at each frame. Does it make sense ? So even MeshLocate() will be removed.
All objects can be easily handled with linkedlist(). Here is a pseudo code:
Code: Select all
Structure Bullet
x.f
y.f
z.f
EndStructure
NewList Bullets.Bullet()
...
Repeat
While NextElement(Bullets())
DisplayMesh(Mesh, Bullets()\x, Bullets()\y, Bullets()\z)
Wend
Until Quit
i like the 2nd idea because as Fred said its a little quicker reading the xyz coords and i like the idea of loading meshes without displaying them. I'm unsure what to suggest for the rotation of the mesh, should this be incorporated into the DisplayMesh() command? or should that command be purely for displaying objects? also if it is incorporated into the DisplayMesh() command would it be relative or absolute coords? i know this command exists: RotateMesh(#Mesh, x, y, z), and is relative, i would also like to see a command to deal with absolute coords too, maybe: RotateMeshAbsolute(#Mesh, x, y, z).
...
...
*later*
infact having a think about it, i think having the rotation would be quite good as part of the DisplayMesh() command. Maybe even a flag to deal with relative and absolute coords for position and rotation.
This would negate the need for seperate rotation commands. As regard to animation these commands should stay seperate.
Also would it be possible for a command to be added to clean up for in between levels to get rid of everything to be ready to start afresh: FlushAll3D() perhaps.
...
...
*later*
infact having a think about it, i think having the rotation would be quite good as part of the DisplayMesh() command. Maybe even a flag to deal with relative and absolute coords for position and rotation.
Code: Select all
;
;DisplayMesh(#MESH, x position, y position, z position, x rotation, y rotation, z rotation [, position coords flag [, rotation coords flag]])
;
;if no flags are specified it defaults to absolute.
;
Structure Bullet
x.f
y.f
z.f
xrot.f
yrot.f
zrot.f
EndStructure
NewList Bullets.Bullet()
...
Repeat
While NextElement(Bullets())
DisplayMesh(Mesh, Bullets()\x, Bullets()\y, Bullets()\z, Bullets()\xrot, Bullets()\yrot, Bullets()\zrot, #PB_ABSOLUTE, #PB_RELATIVE)
Wend
Until Quit
Also would it be possible for a command to be added to clean up for in between levels to get rid of everything to be ready to start afresh: FlushAll3D() perhaps.
--Kale
-
THCM
- Enthusiast
- Posts: 276
- Joined: Fri Apr 25, 2003 5:06 pm
- Location: Gummersbach - Germany
- Contact:
Hi Fred!
Pleases read the whole thread... it got a bit long!
You said the copy mesh command is intelligent and recognizes if the same mesh can be used. Can you explain to me, why my game drops to frame rates of about 10 - 20 fps or even less? I've got a playfield of 13*8 patterns and first I tried to copy 104 objects from my patternset to the displayed ones every frame. Empty objects will be freed the other one overwritten.
So i rewrote my routines with a doublebuffer to check which objects changed, and voila everything is fine running with 60 fps. So why does copying a mesh so much time when only a few references have to be changed? My computer is a P4 with 3.066 GHz and a RadeOn 9800 Pro. Can it be that slow?
How does Purebasic keep track of the meshes or textures? I can copy one mesh to 200 other and then change only one. Or I can change draw to the texture. How does Purebasic know that it has to do a real copy? You can do it, If you always copy a mesh, when the user change the mesh data. But isn't it better if you give this option to the user? Please split meshes to objects and meshes!!!!! You can do lots of fancy stuff if you do!!!
1. Mesh animation (simply change the mesh-number in the object)
2. With copymesh, sizemesh and rotatemesh I can animate lots of Objects or change lots of objects with one command! (Useful in Jump'n'Runs like Sonic with many rotating stars)
3. Real Mesh-Manipulation without hassle
At first I asked for a DisplayMesh command, but after thinking twice I changed my mind as stated a few posts before.
For example if the user has a very slow computer and you have lots of objects on the screen, but only a few change their position, lots of stuff has to be done twice. The Purebasic side has to start lots of DisplayMesh commands which change the display list and Ogre has to display it. If Purebasic only has to change a few one, we can shave a few cycles!
The frame rate of a game can change a lot, but all objects have to move and rotate the same distance as it would run in 60 fps all the time. So every 3D-application has a time variable. Often objects very far away only change their position every second time, but with your second approach I have to call the displaymesh command everytime.
I know it's hard work, but please consider all this. It's long ago I coded 3D-Stuff and those days I had to code the whole engine from scratch! To have a display-list is a must! Just think about the copper in the Amiga! On the c64 I had to keep track of color-changes in my program during display-time, but on Amiga I simply wrote to the copperlist I wanted! With a display-mesh Purebasic has to rewrite the whole list everytime, but with a dynamic display-list only changes have to be applied!
So that's all for now! Keep up Fred, I'll send you my game and please have a look into the slowdowns!
Yours
Pleases read the whole thread... it got a bit long!
You said the copy mesh command is intelligent and recognizes if the same mesh can be used. Can you explain to me, why my game drops to frame rates of about 10 - 20 fps or even less? I've got a playfield of 13*8 patterns and first I tried to copy 104 objects from my patternset to the displayed ones every frame. Empty objects will be freed the other one overwritten.
So i rewrote my routines with a doublebuffer to check which objects changed, and voila everything is fine running with 60 fps. So why does copying a mesh so much time when only a few references have to be changed? My computer is a P4 with 3.066 GHz and a RadeOn 9800 Pro. Can it be that slow?
How does Purebasic keep track of the meshes or textures? I can copy one mesh to 200 other and then change only one. Or I can change draw to the texture. How does Purebasic know that it has to do a real copy? You can do it, If you always copy a mesh, when the user change the mesh data. But isn't it better if you give this option to the user? Please split meshes to objects and meshes!!!!! You can do lots of fancy stuff if you do!!!
1. Mesh animation (simply change the mesh-number in the object)
2. With copymesh, sizemesh and rotatemesh I can animate lots of Objects or change lots of objects with one command! (Useful in Jump'n'Runs like Sonic with many rotating stars)
3. Real Mesh-Manipulation without hassle
At first I asked for a DisplayMesh command, but after thinking twice I changed my mind as stated a few posts before.
For example if the user has a very slow computer and you have lots of objects on the screen, but only a few change their position, lots of stuff has to be done twice. The Purebasic side has to start lots of DisplayMesh commands which change the display list and Ogre has to display it. If Purebasic only has to change a few one, we can shave a few cycles!
The frame rate of a game can change a lot, but all objects have to move and rotate the same distance as it would run in 60 fps all the time. So every 3D-application has a time variable. Often objects very far away only change their position every second time, but with your second approach I have to call the displaymesh command everytime.
I know it's hard work, but please consider all this. It's long ago I coded 3D-Stuff and those days I had to code the whole engine from scratch! To have a display-list is a must! Just think about the copper in the Amiga! On the c64 I had to keep track of color-changes in my program during display-time, but on Amiga I simply wrote to the copperlist I wanted! With a display-mesh Purebasic has to rewrite the whole list everytime, but with a dynamic display-list only changes have to be applied!
So that's all for now! Keep up Fred, I'll send you my game and please have a look into the slowdowns!
Yours
The Human Code Machine / Masters' Design Group
-
THCM
- Enthusiast
- Posts: 276
- Joined: Fri Apr 25, 2003 5:06 pm
- Location: Gummersbach - Germany
- Contact:
Ok, Fred!
I hope that you find what's the reason for the massive slowdowns. I can read from your answer, that you won't change the Interface. This is good news in my opinion.
Furhermore I hope that you include more possibilites to modify object-properties!!!
I'm thrilled of what's coming next!
8O
I hope that you find what's the reason for the massive slowdowns. I can read from your answer, that you won't change the Interface. This is good news in my opinion.
Furhermore I hope that you include more possibilites to modify object-properties!!!
I'm thrilled of what's coming next!
8O
The Human Code Machine / Masters' Design Group