Free Allegiance Forums

Hmmm, using python works perfectly for me.

>>> todoList += "/n* Find out why python installs work differently for different systems"


*ponders if its possible to communicate solely through the medium of pseudocode*

A pinned topic of goals would be very useful. Goals and their priorities.

What are we at for now?

>>> todoList += "/n* Learn Python and our way around Panda3d"

EDIT:
Check this for modeling. Might be useful?

EDIT2:
it's on the Panda3d forums.

sorry, todoList is a write only variable, even I can't access it

seriously, i really need to make one...

fuzzylunkin1 wrote:QUOTE (fuzzylunkin1 @ Feb 1 2009, 08:11 PM) A pinned topic of goals would be very useful. Goals and their priorities.

Seriously, we really need one.

as you can see, ive been focusing on generating the terrain.
this image is using a 1024x1024 heightmap which is a little high, it eats too much processing power, so the game will probably use 256/512 instead.
I may make it player optional so that those with better computers can enjoy a higher quality terrain, but it depends on how much of an effect that has on gameplay (e.g. a player with 1 quality could see somebody how is hidden by a higher detail level) ... actualy a quick test suggests that the circumstances that that could happen in would be so rare that its not worth worrying about, so ill probably make it an option.

if you compare this to the image in my first post, youll see that i have a better lighting system (its not actually shadows, just a more advanced form of lighting) also, the texturing is much better, that may also be less noticeable in the real thing, especially if you have an older graphics card, but ill try to keep it.

most of the improvement in terrain generation comes from a huge improvement in the perlin noise generator. I found a way to speed it up too, it can do a 1024x1024 image in around a second now, rather than the 100 second it was doing earlier (and my original code would have taken 2 days to do it )
I had been suffering from a very strange and annoying problem that took a long time to solve, it turned out to be something i already knew about, i just hadn't realized the seriousness of the issue.
the way a heightmap works is that an image is given to the terrain generator, it then creates the terrain by varying the level of the ground by the colour of the pixel in a corresponding position in the image, but here is the problem, the image only has 256 levels (its an 8bit grayscale) so i only have 256 different heights to work with... that wouldnt be so bad except that the perlin noise only used the middle 3% or so (which is fine when your using floats, since they have a LOT of levels), meaning that I only had 8 or so levels to work with. That is a *serious* problem, all details are lost and in extreme cases you get a very retro layered look. I finally solved it by simply multiplying the perlin noise by 32 before putting it in the image, and suddenly everything was looking beautiful.


EDIT: after a bit of testing, ive discovered a bug in pandas heightfield generator (GeoMipTerrain) that is a little odd, it seems it makes the terrain quality around the focal point really unreliable, sometimes its high as its meant to be and sometimes its much lower for no apparent reason, they have a better version in the CVS apparently but i don't want to compile that version because i want anyone who is interested in development to be able to try it out easily, hopefully they will release it officially soon...

I'm going to pin this thread seeing as Finn has very handily stepped into Radruin's shoes.

Thanks

Indeed, the work you have done so far is just awsome Terrain looks great

Good news, bad news.

Good news: I have got a good, smart and efficient* way of flattening the terrain (important in areas where buildings are going to be placed, since building on rough terrain is always ugly)

Bad news: a function i have absolutely no control over and has to be called is insanely slow, so flattening terrain can take a very long time (exponentially longer depending on the size of the heightmap). So what I had hoped to be an awesome dynamic thing will have to be boring and static

I was going to have it so that you could place buildings anywhere that was valid and the flattener would then flatten it during the building process, but now all buildable areas will have to be flat to begin with, limiting the terrain somewhat.

still a bit of hope: The next version of panda will have some simple threading abilities (i think) and that could allow it to still happen, as long as the build process is long enough for the function to finish.

This does also mean the entire map will need loading at game start, that could mean the game will take a while to load, but alleg already has a 15 second countdown which doesnt do anything so I doubt you guys will even know.

another sad thing, its unlikely ill be able to let the user increase the terrain quality now, as this problem is exponential, someone with just the next level of detail on their terrain would take far far longer to get ingame.



*my code is more efficient than it needs to be in fact

Wait, Panda's open source, right? So couldn't you take a look as to why that specific function is so slow, and posibly make a similar function that's faster? Or would that take too much time?