(2008.09.14 06:06 AM)Kieranator Wrote: [ -> ]So brian is thinking of another release this weekend? I'm hoping this means today. :P
Sorry, hopefully by tuesday, I want to get some more work done on obscuring. I think I have all the crashes clear up (at this point, that is.)
[>] Brian
Quick note of fixes coming in this one:
1) hopefully eliminated all the crashes -- might have to run your map through Editor first
2) Editor detects and fixes problems in maps (like reversed or backwards coordinates, etc.)
3) More idiot proofing for liquids
4) Alex's animator fixes -- model insert doesn't break bone connections, models aren't flipped, and I made it so importing a model with the same names for bones fixes the bone names (appends a number)
5) turning keys work for thrust input mode
6) a "never obscure" flag for space type or small maps when you just want to display all meshes
7) grouped obscuring, obscuring fixes (still have a ways to go but it's better)
One thing I want to work on (for next time) is to change a bit of how dim3 handles textures; I've seen some maps with gigs of textures and it drives the memory requirement through the roof. There isn't a lot I can do, but there's some extraneous data that I can pull out to hopefully shave that down a bit. This version (as a small change) doesn't load textures in Engine that aren't hooked up to anything.
[>] Brian
(2008.09.15 12:09 AM)ggadwa Wrote: [ -> ] (2008.09.14 06:06 AM)Kieranator Wrote: [ -> ]So brian is thinking of another release this weekend? I'm hoping this means today. :P
Sorry, hopefully by tuesday, I want to get some more work done on obscuring. I think I have all the crashes clear up (at this point, that is.)
[>] Brian
Quick note of fixes coming in this one:
1) hopefully eliminated all the crashes -- might have to run your map through Editor first
2) Editor detects and fixes problems in maps (like reversed or backwards coordinates, etc.)
3) More idiot proofing for liquids
4) Alex's animator fixes -- model insert doesn't break bone connections, models aren't flipped, and I made it so importing a model with the same names for bones fixes the bone names (appends a number)
5) turning keys work for thrust input mode
6) a "never obscure" flag for space type or small maps when you just want to display all meshes
7) grouped obscuring, obscuring fixes (still have a ways to go but it's better)
One thing I want to work on (for next time) is to change a bit of how dim3 handles textures; I've seen some maps with gigs of textures and it drives the memory requirement through the roof. There isn't a lot I can do, but there's some extraneous data that I can pull out to hopefully shave that down a bit. This version (as a small change) doesn't load textures in Engine that aren't hooked up to anything.
[>] Brian
Ok then. I'll look forward to tuesday. In the meantime I'll have the next episode of RvB to tide me over.
About the gigs of textures Brian. Remember that no matter how good dim3 is or gets, it's still going to take good optimization on the designers' part to make the game run well. If some body has fifty 1024x1024 textures being used, you can't do much about it, it's up to him/her to fix that speed problem.
(2008.09.15 08:26 AM)Alexander Smith Wrote: [ -> ]About the gigs of textures Brian. Remember that no matter how good dim3 is or gets, it's still going to take good optimization on the designers' part to make the game run well. If some body has fifty 1024x1024 textures being used, you can't do much about it, it's up to him/her to fix that speed problem.
Yeah. then again, 1024x1024 is not ideal for games. one thing that Brian could do is add a setting where textures are automatically scaled down to 512x512 if they are a larger resolution.
1024x1024 is perfect for a detailed character in a 3rd person game or for a car in a racing game.
There's nothing wrong with that. You can't say that "1024x1024 is not ideal for games" because it always depends on how you use your textures.
(2008.09.15 07:42 PM)Bink Wrote: [ -> ]1024x1024 is perfect for a detailed character in a 3rd person game or for a car in a racing game.
There's nothing wrong with that. You can't say that "1024x1024 is not ideal for games" because it always depends on how you use your textures.
That's a fair point- 1024x1024 is good for models and the like. I was just referring to terrain & map textures, where a lot of 1024x1024 textures can kill performance on older systems.
I'm guessing that the "gigs of textures" people are the ones who are being stupid and trying to bake lighting for entire maps. Nothing is going to kill performance like trying to create an entire course with no repeating textures -- and that's true in any engine on the market.
(2008.09.15 08:13 PM)cyst Wrote: [ -> ]and that's true in any engine on the market.
You sure know what you are
talking about.
By the way, Brian, you are not talking about my medieval map by any chance? I mean the PNGs take 40 megs on the HD, the graphics card has 256 megs, how much memory would the engine need for that map? Would that be graphics card or system memory?
Brian: While your working on texture optimization, you might wanna optimize the editor as well. It can run slower than the engine if you drop in too many textures on a model. (although I had more textures than ever reasonably needed on the model, if it can run in the engine it should run in the editor)
Brad:
You know what he means.
(2008.09.15 07:54 PM)Kieranator Wrote: [ -> ] (2008.09.15 07:42 PM)Bink Wrote: [ -> ]1024x1024 is perfect for a detailed character in a 3rd person game or for a car in a racing game.
There's nothing wrong with that. You can't say that "1024x1024 is not ideal for games" because it always depends on how you use your textures.
That's a fair point- 1024x1024 is good for models and the like. I was just referring to terrain & map textures, where a lot of 1024x1024 textures can kill performance on older systems.
1024x1024 is way enough if the UV-map is done correctly.