3D Slow terrain loading. (How to optimize?)

Status
Not open for further replies.
M

Misty

Guest
You won't give people enough detail and claim your solution might already be better, rather than trying it out, when someone tries to help. Then people suggest using the faster Game Maker and you deny that too. It's not surprising that people are frustrated, and it's not surprising that you aren't finding much help.
No, it isn't, but this new guy, slayer 64 seems to stand out of the crowd.
I'd like to hear his advice. It doesn't seem negative and overbearing, but genuinely helpful advice such as how to smooth normals via ds grids.
 

hippyman

Member
Don't see how I've treated anyone badly, I'm not the one creating accusations and disrupting civilized discussions.
I see from your post count, that you made your account just to make this one post.

There's nothing civilized about being too stubborn to except help literally right after asking for it.

Trolling == Civilized == False
 
L

Lotias

Guest
No, it isn't, but this new guy, slayer 64 seems to stand out of the crowd.
I'd like to hear his advice. It doesn't seem negative and overbearing, but genuinely helpful advice such as how to smooth normals via ds grids.
He said it was a solution in GM:S. You know, the program you say you won't use.
 

hippyman

Member
No, it isn't, but this new guy, slayer 64 seems to stand out of the crowd.
I'd like to hear his advice. It doesn't seem negative and overbearing, but genuinely helpful advice such as how to smooth normals via ds grids.
GMS

That means Studio. Which you refuse to use.


Edit: Ninja'd
 
M

Misty

Guest
He said it was a solution in GM:S. You know, the program you say you won't use.
Quick to jump to conclusions are we?

The word he said was gms. He probably meant it as gm's...a simple typo.


There's nothing civilized about being too stubborn to except help literally right after asking for it.
The "help" I was suggested was vertex buffers, seeming to ignore the fact I repetitively stated that my lag wasn't from d3d_models, and a bunch of posts along the lines of posting suggestions about how to calculate timers that seemed to ignore my post right above them.
 
L

Lotias

Guest
Quick to jump to conclusions are we?

The word he said was gms. He probably meant it as gm's...a simple typo.



The "help" I was suggested was vertex buffers, seeming to ignore the fact I repetitively stated that my lag wasn't from d3d_models, and a bunch of posts posting suggestions about how to calculate timers that seemed to ignore my post right above them.
Well unfortunately, nobody knows a thing about what your code even does, specifically. We'd have to see the actual code. Which you won't show us. That's why most of these suggestions won't help you.
 
A

AlphaChannel

Guest
At least some pseudo-code would give a bit of insight into your problem.
 
M

Misty

Guest
Well unfortunately, nobody knows a thing about what your code even does, specifically. We'd have to see the actual code. Which you won't show us. That's why most of these suggestions won't help you.
I gave you much of the needed information to extrapolate reasonable solutions with. And then you bully me to show you my code, and when I don't obey, I get threats from you that you will close my topic down.

For instance, slayer64 doesn't know my code, and yet, it seems, he is already on the right track.

At least some pseudo-code
I did earlier.
 
L

Lotias

Guest
I gave you much of the needed information to extrapolate reasonable solutions with. And then you bully me to show you my code, and when I don't obey, I get threats from you that you will close my topic down.

For instance, slayer64 doesn't know my code, and yet, it seems, he has already on the right track.
No you didn't. I can't tailor suggestions to what barely constitutes as a summary of your scripts.
Slayer64 probably just had to make a guess. Most of us don't have time to play 20 questions with you.
 
M

Misty

Guest
No you didn't. I can't tailor suggestions to what barely constitutes as a summary of your scripts.
Slayer64 probably just had to make a guess. Most of us don't have time to play 20 questions with you.
Slayer64 seems to be man about town who knows the whole terrain game.

What exactly kind of psuedo code do you want if my original wasn't what you were looking for?
 

GMWolf

aka fel666
Slayer64 to the rescue! Im quite interested in this simple trick!

The thing about vertex buffers is not only the lower overhead, but they also allow you to use more efficient algorithms as you can manipulate are buffer then cast it to a vertex buffer.
You also said method calling caused lag. Thats because of interpretation overhead.

We also suggested using a single loop (rejected too).

To give more substancial advice, code is needed. or at least, some outlibe of your algorithm. (What you gave us is far from helpfull)
 

Roa

Member
You can make GMS have a GM8 skin and colour coding. and the IDE should run better on your pc than the GM8 IDE. Not to mention all these horrid functions they made obsolete (if those are the reason you stick with GM8, you have been programming with rather poor style.)
The 3d support of GMS is also ways better than GM8's.
lmao, No, dont miss understand me. I'm saying to move up to GM studio. That I originally had a hard time making the change


Crap experience? My computer can run Quake 3 just fine, and in my opinion those are all the level of graphics games need, anything else begins to overburden the developer with detail, just look at Quake 4, supposed "progress", yet much aesthetically inferior to Quake 3 in my opinion.

That's 250 dollars more than I can afford.

Dude, you're not using a c level engine to make graphics though. Also throwing polygons and textures at any machine is nothing. I can run source maxed out on intelHD4000k. I can run unreal 2004 on max. There are no shaders. Saying you run quake 3 is not impressive.


Also, you're 25, you can't afford 250 bucks at a one time price to make your life better?
You weren't being stupid and here's why...first of all, it's not stupid to sit on the couch on the fence and comfort yourself, metaphorically speaking, second of all, by limiting yourself to gm8's standards, you make your game that much more efficient and optimized, and when it goes to GM STUDIO, you can apply all of the special optimizations such as vertex buffers to make it run even faster
Comfort leads to laziness. It means you settle for things and wont change. If you aren't willing to improve the experience to get things done, then no one here can help you and the topic is pointless. No one even has any code yet.

Also, porting to GMS vs making something in gm8 isnt even comparable, even after the port. The options available and optimization techs used are completely different so its irrelevant what you do in GM8. I spent 5 long years of my life optmizaing 3d in GM6, and all that has been forgotten because it is completely worthless now. You can't apply those things today.
 
A

AlphaChannel

Guest
Slayer64 seems to be man about town who knows the whole terrain game.

What exactly kind of psuedo code do you want if my original wasn't what you were looking for?
As in explaining which specific built in functions are in use, some of the structure (more than just an oversimplified abstraction, detail is important when finding bottlenecks)
 
M

Misty

Guest
lmao, No, dont miss understand me. I'm saying to move up to GM studio. That I originally had a hard time making the change
That's not what I'm saying. I'm saying, I had no trouble moving up to studio, but I prefer the aesthetics of the GM8 IDE.




Dude, you're not using a c level engine to make graphics though. Also throwing polygons and textures at any machine is nothing. I can run source maxed out on intelHD4000k. I can run unreal 2004 on max. There are no shaders. Saying you run quake 3 is not impressive.
Never said it was impressive, was simply saying Quake 3 is all the graphics gamers (and game makers) really need.


Comfort leads to laziness. It means you settle for things and wont change. If you aren't willing to improve the experience to get things done, then no one here can help you and the topic is pointless. No one even has any code yet.
And yet it seems, Slayer64 already has a solution that will help me.



Also, you're 25, you can afford 250 bucks at a one time price to make your life better?
Not all of us are middle class citizens.

We also suggested using a single loop (rejected too).
Seems you guys didn't read all of what I said.
I said it would be impractical to use a single loop. Further more, I also stated that the issue is is irrelevant, because the extra loop only takes up 0.3 seconds of computation time.


As in explaining which specific built in functions are in use, some of the structure (more than just an oversimplified abstraction, detail is important when finding bottlenecks)
Already said the functions, ds_grids and d3d_model calls, those are the only functions.
 
A

AlphaChannel

Guest
Also, you're 25, you can afford 250 bucks at a one time price to make your life better?
As if quality of life depended on having decent specs.
It would make life as a dev easier, but you can't assume everyone has at least 250 to dish out every generation of pc hardware. {Note: I have a decent spec machine so I'm not just hating}
 

GMWolf

aka fel666
0.3 seconds of computation time.
per step? this ist clear. again, code would help.

Loop 1. Set the grid values using ds_set_grid() using a loop.
2. Read then add the grid values to the models in a loop right below it. Also in this loop there are a bunch of find_normal calls in order to smooth normals.
Not helpful.

Code:
g <- heigtmap grid
m <- model

for all points in grid (x, y) {
    g[x,y] = get_height(x, y); //some methods that get the height
}

for all points in grid (x, y) {
    p1 = g[x, y];
    p2 = g[x + 1, y];
    p3 = g[x, y + 1];
    p4 = g[x + 1, y + 1];
    add triangle p1, p2, p3 to m
    add triangle p3, p2, p4 to m
}
helpful.

THis is the kind of stuff we need to help you. it allows to see how your code flows, and where we can optimize.
The actual code would be even better...
 

Roa

Member
Slayer64 hasn't said anything lol. He just said you could smooth them. I could believe he would have a trick up his sleeve, but again, optimizations don't transfer well. Also, 250 bucks for something that last years is chump change, even for someone with nothing but a part time min wage job. The value a good PC adds is far worth it. You can afford internet and stuff clearly, so you're not in the bucket list.

There are other skins for GMS, I don't know what to tell you if you don't want the upgrade. You're probably better off spending your time coming up with ideas than posting here. I already said most members would prefer to leave legacy behind. If you're willing to sacrifice an all around better system for something as fickle as one or two cosmetic changes, then we can't help.
 

GMWolf

aka fel666
As if quality of life depended on having decent specs.
It would make life as a dev easier, but you can't assume everyone has at least 250 to dish out every generation of pc hardware. {Note: I have a decent spec machine so I'm not just hating}
I agree. Not everyone has cash on hand.
but someone with trade secrets must do...
 
M

Matthew

Guest
The code is basically like this.

Create all empty models and empty grids in the create event.

In the Draw Event, load 1 chunk each frame. (This uses 2 loops.
Loop 1. Set the grid values using ds_set_grid() using a loop.
2. Read then add the grid values to the models in a loop right below it. Also in this loop there are a bunch of find_normal calls in order to smooth normals.

After several frames (and seconds) the model will complete. The loading allows the player to move in real time before the terrain is loaded, but it takes 11 seconds and causes the framerate to be 1 fps.
I can fix this without looking at your code. Your problem is right here; You're using two loops. Smart people only use one.
 
M

Misty

Guest
You can afford internet and stuff clearly, so you're not in the bucket list.
What I said earlier about erroneous correlations...

per step? this ist clear. again, code would help.
It was clear when I said it at first, this is me repeating myself, during those times things become less clear.
I can fix this without looking at your code. Your problem is right here; You're using two loops. Smart people only use one.
Smart people read the posts above, which said that it only takes 0.3 seconds...and if you read closely earlier, meaning not per step, 0.3 seconds period.
 

Roa

Member
I can fix this without looking at your code. Your problem is right here; You're using two loops. Smart people only use one.
He already said he wont change it. We've already suggested this. He writes the data in, then reads it back out.
 
A

AlphaChannel

Guest
Anyways, I see Misty's point of view with GM8. I loved Gm8, a lot, but thinking about it seriously and objectively, a FREE upgrade that comes with hugely increased CPU/GPU efficiency and performance + the possibility of multiple export platforms, rejected solely based on confort and "aesthetics", I find quite difficult to understand.
 
M

Matthew

Guest
What I said earlier about erroneous correlations...


It was clear when I said it at first, this is me repeating myself, during those times things become less clear.

Smart people read the posts above, which said that it only takes 0.3 seconds...and if you read closely earlier, meaning not per step, 0.3 seconds period.
Why are you the arbiter of intelligence? I can think of fifteen better candidates that can't even tie their own shoes.
 
M

Misty

Guest
He already said he wont change it. We've already suggested this. He writes the data in, then reads it back out.
Let's say you read it wrong. Let's say that I meant 0.3 seconds per step not per generation.
Earlier I mentioned each chunk is generated 1 chunk per frame, then I said there are 4 chunks. I also said the problem is it takes 11 seconds to load. 0.3*4 = 1.2 seconds...
So even if you thought I meant per step, still no excuse, that's only 10 percent of computation time, out of 11 seconds, mostly insignificant since you also factor in the fact that such a low amount would be able to be shaved off. And that's an "even if" since in actuality it's .3 seconds out of 11 seconds, not 1.2 seconds....
Please hammer about vertex buffers again, so I can shave off 0.3 seconds of computation time.

Why give the code if you won't bother to do the calculations?
 
P

PlayLight

Guest
For F*&k sake, can we all just ignore this topic and stop posting on it! I'm so sick of seeing it in the list.
You have All helped way more than necessary. Just ignore it and move to helping members who deserve your time.

To the OP: if you only want advice from Slayer64, then use your head and contact him directly!
 

GMWolf

aka fel666
In the Draw Event, load 1 chunk each frame.
So the code gets executed every step.

In fact the main cause of lag was NOT the d3d_model definitions at all, which only took 0.3 seconds.
The d3d_model definitions take 0.3 seconds. (so far, in total when the game finished loading? or per frame? not clear)

because the extra loop only takes up 0.3 seconds of computation time.
apparently the d3d_model definitions are in the second loop. ok.

not per step, 0.3 seconds period.
so its 0.3 seconds in total? now we need to know how over how many frames this test was done. the 0.3 second metric is far from useful.

granted, it would still be a small portion of the 11 seconds. However 0.3 seconds per frame would have explained the awefull 1fps.

Please hammer about vertex buffers again, so I can shave off 0.3 seconds of computation time.
Actually, vertex buffers are not just a faster version of d3d_models
they allow you to do tricks when using normal buffers, greatly reducing the overhead when defining the heightmap.
If using a image heightmap, for example, you can convert the image straight into a buffer with all the height information you may need. (see
).

You can save and load buffers quickly (usefull if working with infinite terrain. see
)
You can even save and load asynchronously. making loading assets at load time far easier on your fps.

however, as with anything, buffers will only get you so far. Optimizing your algorithm is far more important. (unless you have image based heightmaps. check the first youtube link).

With procedural generation, most of the performance is probably lost there. however, you havent supplied us with much with regards to that.
Maybe if you could supply us with more information we can point you to the right direction.
 
Last edited:
M

Misty

Guest
Why are you the arbiter of intelligence? I can think of fifteen better candidates that can't even tie their own shoes.
I heard of a 160 IQ guy who can't tie his shoes nor socialize so your statement is meaningless.

For F*&k sake, can we all just ignore this topic and stop posting on it! I'm so sick of seeing it in the list.
You have All helped way more than necessary. Just ignore it and move to helping members who deserve your time.

To the OP: if you only want advice from Slayer64, then use your head and contact him directly.
So hostile and demanding. Noone forced you to post in this topic I certainly didnt.
 
A

AlphaChannel

Guest
Let's say you read it wrong. Let's say that I meant 0.3 seconds per step not per generation.
Earlier I mentioned each chunk is generated 1 chunk per frame, then I said there are 4 chunks. I also said the problem is it takes 11 seconds to load. 0.3*4 = 1.2 seconds...
So even if you thought I meant per step, still no excuse, that's only 10 percent of computation time, out of 11 seconds, mostly insignificant since you also factor in the fact that such a low amount would be able to be shaved off. And that's an "even if" since in actuality it's .3 seconds out of 11 seconds, not 1.2 seconds....
Please hammer about vertex buffers again, so I can shave off 0.3 seconds of computation time.

Why give the code if you won't bother to do the calculations?
Whether or not he completely understood based off of your "easy to extrapolate" (yet ambiguous explanation of YOUR problem) is irrelevant to why you should or should not help YOURSELF by making it easier to help you acheive a solution.
 
M

Misty

Guest
so its 0.3 seconds in total? now we need to know how over how many frames this test was done. the 0.3 second metric is far from useful.
4 chunks, 1 chunk per frame...remember? So that's 4 frames.

Actually, vertex buffers are not just a faster version of d3d_models
they allow you to do tricks when using normal buffers, greatly reducing the overhead when difining the heightmap.
There is no heightmap...
 
M

Matthew

Guest
I'm sure the crippled super genius who can't tie his shoes is the rule, not the exception. You're the first to bring the ability to socialize into this, though, so I sense a bit of projection.
The fact that you're calling someone else hostile and demanding is funny, though. Here's a gun. I am fairly sure you can extrapolate exactly what needs to be done given the information you have been given.
 

Roa

Member
Yeah....
This is getting stupid.


here is the skinny. You have 4-5 people all saying the same things, things you are not willing to compromise on, things you turn your nose up at on a whim. We are at page 2 and so far, nothing is good enough for you. This is gone on long enough and is getting derailed. Either post all the code or I'm clocking out. These people are genuinely trying to help you.
 
M

Misty

Guest
I'm sure the crippled super genius who can't tie his shoes is the rule, not the exception. You're the first to bring the ability to socialize into this, though, so I sense a bit of projection.
The fact that you're calling someone else hostile and demanding is funny, though. Here's a gun. I am fairly sure you can extrapolate exactly what needs to be done given the information you have been given.
Yes, I can extrapolate what needs to be done.:cool:

Yeah....
This is getting stupid.


here is the skinny. You have 4-5 people all saying the same things, things you are not willing to compromise on, things you turn your nose up at on a whim. We are at page 2 and so far, nothing is good enough for you. This is gone on long enough and is getting derailed. Either post all the code or I'm clocking out. These people are genuinely trying to help you.
Here's a thought. Why don't YOU, post the code , YOURSELF. How exactly would memory buffers help me in this instance Show me the code.
 
M

Matthew

Guest
He asks for help, refuses to post his code, and then demands the people he's begging for help to post their code.

Even I'm amazed.
 
A

AlphaChannel

Guest
What? if there is no heightmap, then you must be using voxels or something...
(a ds_grid of height values is a heightmap. it maps a height value to a vector).
We should of EXTRAPOLATED this guys! WE are such idiots. How could we NOT know exactly what the problem is?


Here's a thought. Why don't YOU, post the code , YOURSELF. How exactly would memory buffers help me in this instance Show me the code.
You don't seem to get, noone can code anything that will be magically compatible with your mysteriously secret code.

Try arguing against real world results.
Like for example, I have used both GM8 and GMS. Frame rates HAVE measurably improved. Real world enough?
 
M

Misty

Guest
What? if there is no heightmap, then you must be using voxels or something...
(a ds_grid of height values is a heightmap. it maps a height value to a vector).
I misunderstood. However I invite you to show me the code and how it would help, I stated earlier that ds_grid only causes 0.6 seconds of lag en total.
That depends on your method of generating height values.
Please tell us.
Trade secret, as I said before.

We should of EXTRAPOLATED this guys! WE are such idiots. How could we NOT know exactly what the problem is?



You don't seem to get, noone can code anything that will be magically compatible with your mysteriously secret code.
I'll make it compatible.
 

Roa

Member
Yes, I can extrapolate what needs to be done.:cool:
Here's a thought. Why don't YOU, post the code , YOURSELF. How exactly would memory buffers help me in this instance Show me the code.
lol, that's not how this works. I'm not going to write a bunch of code in hope it appeases someone. You have the code, and we are solving problems with it. I'm not writing anyone anything. You can pay me for that if you want. And I'm not going to even touch buffers when you wont even touch GM studio. How much of my time do you expect me to waste? You've already done enough of that and the only reason I stay is that I'm completely baffled. I don't want vague ideas. I want code. All of it, or I'm gone.
 
Last edited:
M

Matthew

Guest
I'm beginning to think there is no code and OP is having a giggle.
 

GMWolf

aka fel666
Try arguing against real world results.
I no longer have GM8, so i cant give you a categoric proof.
granted, most games will not see that much of an improvement, but more intesive tasks such as procedural generation tends to use a lot of recursion and loops. Interpreters are very bad at that, and i have found that the GMS runner would sometimes decimate gm8 performance. The yyc would in turn decimate the GMS runner. Again, with computationally intensive tasks.

Trade secret, as I said before.
so most of your performance is being eaten right here, and we dont even know what technique you are using?

ok: guessing time you are using one of the following:
  • Fractal Noise
  • white noise
  • pink noise
  • perlin noise (woops, you said no there)
  • hydraulic erosion
  • heat erosion
  • wind erosion
  • hydrothermal plume data
  • simplex noise
  • voronoise
  • voronoi cells for biomes
  • voronoi (where the height is the distance to the edge)
and just like that i gave out "trade secrets".
Back to useful stuff (because im nice like that):
http://www.redblobgames.com/maps/terrain-from-noise/
some nice code in there. the whole website is good in general.
 
Last edited:
L

Lotias

Guest
Try arguing against real world results.

I have yet to see an occasion where my code is sped up by the YYC. Although my code is alway very efficient and tight.

Maybe the YYC only speeds up sloppy coding practices.
It speeds up math heavy code. For some people, they won't be seeing much of a speed increase.

Yes, I can extrapolate what needs to be done.:cool:


Here's a thought. Why don't YOU, post the code , YOURSELF. How exactly would memory buffers help me in this instance Show me the code.
 
A

AlphaChannel

Guest
I'll make it compatible.
If you have the ability of somehow taking someones time to write code with unknown context, and you can apparently "make it compatible", then I can surely extrapolate the fact that you could come up with the buffer code yourself, as you know the way its going to be used best (your the only one here who knows the code), and have the skill based on your ability to "make it compatible"...
 
L

Lotias

Guest
Exactly my point.

For Fel to catagorically say the YYC is 10x to 100x faster than the runner is, well... (See meme in previous post). It depends on the code.

For non-computationally expensive applications the speed is 1:1.
You said it might only speed up sloppy code.
 
M

Misty

Guest
  • Fractal Noise
  • white noise
  • pink noise
  • perlin noise (woops, you said no there)
  • hydraulic erosion
  • heat erosion
  • wind erosion
  • hydrothermal plume data
  • simplex noise
  • voronoise
  • voronoi cells for biomes
Incorrect, none of those.
 
L

Lotias

Guest
Incorrect, none of those.
Alright, here's what I can guess about how your code works.
  • Fill a medium sized pot with cold water. Place it on the stove on high heat. Bring to a boil.
  • Carefully place the spaghetti into the boiling water, making sure the spaghetti is completely covered with water. You may need to break the spaghetti in half. Bring water back to the boil, stirring the pasta lightly to keep it from sticking and reduce the heat so it doesn't boil over.
  • Cook for 7-15 minutes, depending on your preference, the type of pasta and package directions.
  • Remove pot from heat. Drain the pasta in the sink using a colander or large strainer, then transfer pasta to a plate. Serve immediately.
 
Status
Not open for further replies.
Top