Jump to content


Photo

Coding for the new 3D system....


  • This topic is locked This topic is locked
82 replies to this topic

#1 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4465 posts
  • Version:GM:Studio

Posted 04 May 2011 - 07:42 AM

General rules.

Draw as much as you can in a single draw call. This means put as much into a GM model as you can.

If you draw <1000 polys (more on larger systems), the CPU will get in the way, and the GPU will get bored and have an affair with your HardDisk and thereby slowing your game down even more. :P

The more you can draw, the more time your CPU will have to execute other game code. The CPU and GPU work in parallel with large models.

Skin your models - even buildings and terrain. This allows large sections of a world to be rendered in one go, rather than a brick at a time.

Never, ever, draw QUADS if you can possibly avoid it. Your graphics card WILL hate you.


Anything else.....?
  • 0

#2 ~Dannyboy~

~Dannyboy~

    ~hoqhuue(|~

  • GMC Member
  • 2144 posts
  • Version:GM8

Posted 04 May 2011 - 08:19 AM

This is probably a silly question, but... Are you suggesting that if we have to draw 500 poly's it would be faster to batch them with another 500 invisible poly's to stop the GPU getting bored? Or is it more just about drawing 1 lot of 1000 poly's rather than 2 lots of 500?

EDIT: I understand that the second point is obviously true. My main question is the first one, that is, is it faster to draw 1000 poly's than 500?

Edited by ~Dannyboy~, 04 May 2011 - 08:32 AM.

  • 0

I cannot comprehend how intelligent people who spend much of their time designing and creating graphics, audio and code
refuse to believe that they themselves must have been designed and created.

Table Soccer | Yet Another Pacman | Astroblobs | GM Credits | GM Lego NXT | My Site

Posted Image


#3 Phantom107

Phantom107

    Graphics Enthusiast

  • GMC Member
  • 2714 posts
  • Version:GM:Studio

Posted 04 May 2011 - 08:28 AM

This is probably a silly question, but... Are you suggesting that if we have to draw 500 poly's it would be faster to batch them with another 500 invisible poly's to stop the GPU getting bored? Or is it more just about drawing 1 lot of 1000 poly's rather than 2 lots of 500?

Modern GPUs are optimized to draw thousands of polygons in as few draw calls possible.

It's faster to draw 10000 triangles in 1 draw call than 2 draw calls of 5000 triangles each.
  • 0

GMCsig.png


#4 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4465 posts
  • Version:GM:Studio

Posted 04 May 2011 - 08:44 AM

This is probably a silly question, but... Are you suggesting that if we have to draw 500 poly's it would be faster to batch them with another 500 invisible poly's to stop the GPU getting bored? Or is it more just about drawing 1 lot of 1000 poly's rather than 2 lots of 500?

EDIT: I understand that the second point is obviously true. My main question is the first one, that is, is it faster to draw 1000 poly's than 500?



No, if you only need 500 polys, then don't draw "invisible" ones, your just wasting bandwidth doing that. If you CAN batch more into a call, then do so. There's no point drawing doing 20 calls where 1 would do. For "world" models (those that don't need a separate matrix), then try and batch them together so you minimize calls.

Main rule... don't CALL drawing more than you have to. By all means keep things in "chunks" so you can cull nicely, but keep those chunks reasonably large if you can.
  • 0

#5 ~Dannyboy~

~Dannyboy~

    ~hoqhuue(|~

  • GMC Member
  • 2144 posts
  • Version:GM8

Posted 04 May 2011 - 09:58 AM

Thank you for that clarification. ^_^
  • 0

I cannot comprehend how intelligent people who spend much of their time designing and creating graphics, audio and code
refuse to believe that they themselves must have been designed and created.

Table Soccer | Yet Another Pacman | Astroblobs | GM Credits | GM Lego NXT | My Site

Posted Image


#6 Phantom107

Phantom107

    Graphics Enthusiast

  • GMC Member
  • 2714 posts
  • Version:GM:Studio

Posted 04 May 2011 - 10:15 AM

So Mike, are you going to provide GM8.1 with a system that can disable certain batches over distance? Making a ton of distance checks in GML can really hurt performance.
  • 0

GMCsig.png


#7 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4465 posts
  • Version:GM:Studio

Posted 04 May 2011 - 11:08 AM

Nope... you'll have to do that in GML. That would require a proper model format, and we're not adding that here. sorry. There is a new distance in 3D GML command though, I'm sure that'll help :)
  • 0

#8 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7479 posts
  • Version:GM:Studio

Posted 04 May 2011 - 11:51 AM

Anything else.....?

Not entirely related, but I was wondering if these same kinds of awesome performance improvements are also going to be reflected in the iPod, Android and PSP engines in the future, or is 3D still a no-go area there?

Nope... you'll have to do that in GML. That would require a proper model format, and we're not adding that here. sorry. There is a new distance in 3D GML command though, I'm sure that'll help :)

Would it make sense that as a next best thing, we'd have a command that can concatenate models into a single model? I can hardly imagine it, but could this still be faster than drawing separate models? Concatenated models would allow us to combine models on the fly without having to define vertices and basic shapes independently, nor draw models independently. Preferably this uses transformation commands in between adding models to have them scaled, moved and rotated according to our needs, for example,

model=d3d_model_create();d3d_model_add(model,othermodel1);d3d_model_add_translation(xt,yt,zt);d3d_model_add(model,othermodel2);d3d_model_add_rotation(xr,yr,zr);d3d_model_add(model,othermodel3);...d3d_model_draw(model,x,y,z,texid)

(Transformations with respect to the drawing position)

Edited by Smarty, 04 May 2011 - 11:52 AM.

  • 1

#9 Phantom107

Phantom107

    Graphics Enthusiast

  • GMC Member
  • 2714 posts
  • Version:GM:Studio

Posted 04 May 2011 - 12:37 PM

I can hardly imagine it, but could this still be faster than drawing separate models?

It should improve performance a lot.

Take a look at the modern graphics pipeline: (image copyright nVidia Corporation)

Posted Image

As you can see, primitive assembly is required and eats away precious performance. By merging models as you suggested you're effectively making the amount of primitives a lot lower. That will result in less work for the graphics pipeline and thus increasing performance.
  • 0

GMCsig.png


#10 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7479 posts
  • Version:GM:Studio

Posted 04 May 2011 - 01:24 PM

It should improve performance a lot.

Take a look at the modern graphics pipeline: (image copyright nVidia Corporation)

Posted Image

As you can see, primitive assembly is required and eats away precious performance. By merging models as you suggested you're effectively making the amount of primitives a lot lower. That will result in less work for the graphics pipeline and thus increasing performance.

But in turn, more time is spent at the CPU which needs to merge the models together first (including transformations, to make things more useful). Note that this is a process one would intend to perform regularly, likely just before every time I wish to actually draw the model.

I really don't know if the performance boost at the GPU end makes up for the performance penalty at the CPU end, in that case.

EDIT: In spite of the demonstrations, I am also unsure if the execution of model drawing in parallel to game code execution is useful. Typically, drawing happens at the end of a step rather than in the middle, which means most of the logic pertaining to the game has already been taken care of. That is, unless it's still drawing while the engine is busy milling through the next step. How is that synced to the screen?

Edited by Smarty, 04 May 2011 - 01:31 PM.

  • 0

#11 Phantom107

Phantom107

    Graphics Enthusiast

  • GMC Member
  • 2714 posts
  • Version:GM:Studio

Posted 04 May 2011 - 01:56 PM

I really don't know if the performance boost at the GPU end makes up for the performance penalty at the CPU end, in that case.

Merging should not be used on the fly, but only in the create event. There is no need to merge models that are supposed to move (such as the player and items), because you'd be doing the same work that the graphics pipeline is optimized for. It would just be a waste of resources.

However, where it should be used, and where it will provide a great boost, is with static objects. Think of houses, trees and rocks. By merging those up you invest a tiny bit of processing time in the create event, but you will benefit every single frame. Without any extra CPU processing. Think of it as merging objects into areas of 1000x1000x1000, where areas are hidden depending on their distance to the camera.
  • 0

GMCsig.png


#12 NakedPaulToast

NakedPaulToast

    GM Studio/Mac/Win

  • GMC Member
  • 8480 posts
  • Version:GM:Studio

Posted 04 May 2011 - 01:56 PM

Any chance the runner can provide some basic gpu information and features to the games?
  • 0

keep_crap_150_zpsd7af69c5.png


#13 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7479 posts
  • Version:GM:Studio

Posted 04 May 2011 - 02:27 PM

Merging should not be used on the fly, but only in the create event. There is no need to merge models that are supposed to move (such as the player and items), because you'd be doing the same work that the graphics pipeline is optimized for. It would just be a waste of resources.

Actually this was the whole point of my question. I honestly can't tell which of the two - the CPU or the GPU would be faster performing, essentially, different tasks with similar outcome. The entire question was there to focus on investigating which would or could be the faster implementation of the two.

However, where it should be used, and where it will provide a great boost, is with static objects. Think of houses, trees and rocks. By merging those up you invest a tiny bit of processing time in the create event, but you will benefit every single frame. Without any extra CPU processing. Think of it as merging objects into areas of 1000x1000x1000, where areas are hidden depending on their distance to the camera.

The reason to want it to happen on the fly is to be able to provide for a mechanism to animate models, without introducing a proper model format. Since there already are other ways of building complex models, having a merger command mostly for convenience isn't really that interesting...
  • 0

#14 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 1953 posts
  • Version:GM:Studio

Posted 04 May 2011 - 03:06 PM

General rules.

Draw as much as you can in a single draw call. This means put as much into a GM model as you can.

If you draw <1000 polys (more on larger systems), the CPU will get in the way, and the GPU will get bored and have an affair with your HardDisk and thereby slowing your game down even more. :P

The more you can draw, the more time your CPU will have to execute other game code. The CPU and GPU work in parallel with large models.

Skin your models - even buildings and terrain. This allows large sections of a world to be rendered in one go, rather than a brick at a time.

Never, ever, draw QUADS if you can possibly avoid it. Your graphics card WILL hate you.


Anything else.....?


So basically, the way GM is now drawing models is similar to the way we would learn to do it if creating our own 3d engine, and therefore the same way modern 3d engines do it(except for the fancy stuff of course). Therefore, the way to optimize is the same as with any other 3d engine. I'm not going to repeat your post, but rather clarify that if someone needs optimization here, they can now apply public knowledge as far as 3d engines go, instead of only GM specific knowledge.

I'm glad 3d in GM is getting these improvements. But, it won't really be useful to me until we get some sort of animation, either bone or keyframe, of course bone being the much better option. But this is a great first step.
  • 0

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.


#15 FredFredrickson

FredFredrickson

    Artist

  • Global Moderators
  • 9210 posts
  • Version:GM:Studio

Posted 04 May 2011 - 03:09 PM

The reason to want it to happen on the fly is to be able to provide for a mechanism to animate models, without introducing a proper model format. Since there already are other ways of building complex models, having a merger command mostly for convenience isn't really that interesting...

I could see tremendous value in a slower-to-execute but quicker-to-draw function that merged many models into one chunk. You can do this currently to some extent, but you can't draw models with multiple textures in one larger model, so it's only useful for many objects that share the same texture, and often, those objects are not always going to be placed close enough together to take advantage of being grouped into a single model.
  • 0

#16 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7479 posts
  • Version:GM:Studio

Posted 04 May 2011 - 04:13 PM

I could see tremendous value in a slower-to-execute but quicker-to-draw function that merged many models into one chunk.

I'm not saying there is no value. I'm only saying it isn't as interesting.

You can do this currently to some extent, but you can't draw models with multiple textures in one larger model, so it's only useful for many objects that share the same texture, and often, those objects are not always going to be placed close enough together to take advantage of being grouped into a single model.

That's not true - the purpose of being able to combine multiple models into one and be able to add translations and transformations on the fly to the added models is to provide an alternate mechanism of an animated model - a vehicle or a character, for example. And having a single texture for those is mostly exactly what you'd want.

Edit: I already said that.

Edited by Smarty, 04 May 2011 - 04:15 PM.

  • 0

#17 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4465 posts
  • Version:GM:Studio

Posted 04 May 2011 - 08:08 PM

This would be incredibly slow... you'd be back to worse than the original speed as it has to do all that work, and more! You also have the issue of multiple textures. Unless the model has been generated with a single skin that works for both models, then it wouldn't work anyway, and if it HAS been done like that, then why isn't it part of the same model anyhow?

The rule is... make the models once, and never touch them again. This gives you by far the best performance. It's probably something you have to play with to know what's best, but having to "skin" a model will likely restrict what you can bundle anyway.
  • 0

#18 Desert Dog

Desert Dog

    GMC Member

  • GMC Elder
  • 6409 posts
  • Version:Unknown

Posted 04 May 2011 - 09:51 PM

I guess I'm going to play the role of the ignorant guy. :(

Never, ever, draw QUADS if you can possibly avoid it. Your graphics card WILL hate you.

What are QUADS?

If you draw <1000 polys (more on larger systems), the CPU will get in the way, and the GPU will get bored and have an affair with your HardDisk and thereby slowing your game down even more.

Also,

I read on your blog how we now (or will have) static models, and dynamic models, rather than just dynamic.

You say you want calls to be big as possible, is this just for static models?

If I was to draw simple block, would it be 'best' if I use d3d_draw_block for what I understand would be a dynamic model, rather than creating a relatively tiny block model, which would be static, and the constant small drawing calls may get the cpu/gpu tangled up?

What I have in mind is a 3d breakout game type set up, where you have 100+ odd simple blocks(or other relatively low-poly models). Because these things are being destroyed, you cannot make them one big model.

How would you program this? Would using d3d_draw_block stop the cpu&gpu getting in each others way, and make a faster game, or is it 'business as usual' like we did before.. just turn them into models, and draw that, and even though the cpu/gpu are messing up, and slowing things down, it's still a lot faster.
  • 1
HTML5 games for mobile:
HexDogs Bugz Burn! Captain George Golfing Block Memory

Games for Androids
*NEW* Word Dog - Published by Dangerous_Dave


Code: General Array Functions - GM-S friendly. sorting, shuffling. Includes a quicksort.
Use the quicksort to sort ds_lists 10-18 times faster than ds_list_sort()!

#19 Manuel777

Manuel777

    InvaderGames

  • GMC Member
  • 3553 posts
  • Version:GM:Studio

Posted 04 May 2011 - 10:26 PM

Simple rules i used to follow anyway, GM's 3d was always quicker when drawing a single model rather than many. ;)
  • 0

#20 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4465 posts
  • Version:GM:Studio

Posted 05 May 2011 - 08:50 AM

What are QUADS?

rectangles, squares, 2 triangles etc...

If I was to draw simple block, would it be 'best' if I use d3d_draw_block for what I understand would be a dynamic model, rather than creating a relatively tiny block model, which would be static, and the constant small drawing calls may get the cpu/gpu tangled up?


If the model never changes (except texture), then make a static cube. it's ALWAYS faster if it's static. Of course... being static, you could now "round" the edges of the block if you wanted, making it a little nicer to look at. :)

If you need a different size, then make a "unit" cube (1x1x1 in size), then use matrix scaling to make it the correct size. (same for spheres etc.)

If your building the same model over and over again, then this sounds like it should be a static one...

On iOS, it's a little different.. but I'm not getting into that just now.
  • 0

#21 Desert Dog

Desert Dog

    GMC Member

  • GMC Elder
  • 6409 posts
  • Version:Unknown

Posted 05 May 2011 - 09:53 AM

Thanks for that!

Yeah, so it sounds like it's pretty much business as usual then.. that was always the smart way to do 3d in GM... use models, make as few draw calls as possible, etc.

The only real difference as it seems to me is that know it seems we have the power here to draw high poly models lightning fast... in fact, if I'm reading you correctly, it's faster than low poly models because of gpu/cpu mix-mash. (which sounds bizarre!!)

Edited by Desert Dog, 05 May 2011 - 09:53 AM.

  • 0
HTML5 games for mobile:
HexDogs Bugz Burn! Captain George Golfing Block Memory

Games for Androids
*NEW* Word Dog - Published by Dangerous_Dave


Code: General Array Functions - GM-S friendly. sorting, shuffling. Includes a quicksort.
Use the quicksort to sort ds_lists 10-18 times faster than ds_list_sort()!

#22 Manuel777

Manuel777

    InvaderGames

  • GMC Member
  • 3553 posts
  • Version:GM:Studio

Posted 05 May 2011 - 10:09 AM

in fact, if I'm reading you correctly, it's faster than low poly models because of gpu/cpu mix-mash. (which sounds bizarre!!)

It might at first, but its understandable given nowadays graphic cards have a LOT of power.. youre literally wasting it.


So, how are we gonna handle compatibility issues now? are the surfaces alerts going to pop up?

Edited by manuel777, 05 May 2011 - 10:09 AM.

  • 0

#23 Maarten Baert

Maarten Baert

    GMC Member

  • GMC Member
  • 750 posts
  • Version:GM8.1

Posted 05 May 2011 - 12:11 PM

If you need a different size, then make a "unit" cube (1x1x1 in size), then use matrix scaling to make it the correct size. (same for spheres etc.)

That doesn't work if you use lighting, scaling messes up the normals.

Is there a render state like D3D9's D3DRS_NORMALIZENORMALS in DirectX 8? It would be really useful if we had a function to enable and disable it. I know it's slower (on low-end video cards at least), but it's still better than weird lighting.
  • 0
Posted Image

#24 amd42

amd42

    GMC Member

  • GMC Member
  • 269 posts
  • Version:GM8

Posted 05 May 2011 - 01:58 PM

That doesn't work if you use lighting, scaling messes up the normals.

Is there a render state like D3D9's D3DRS_NORMALIZENORMALS in DirectX 8? It would be really useful if we had a function to enable and disable it. I know it's slower (on low-end video cards at least), but it's still better than weird lighting.


Looks like Mike Dailly's already one step ahead of you: glog comment
  • 0
"Computers in the future may weigh no more than 1.5 tons." - Popular Mechanics, 1949

#25 Nocturne

Nocturne

    Nocturne Games

  • Administrators
  • 23634 posts
  • Version:GM:Studio

Posted 05 May 2011 - 02:15 PM

Okay I am a 3D noob... BUT if a quad is a square or two triangles, isn´t that how GM deals with sprites? Two triangles textured from the sprite? And if so, then does my graphics card hate me for using sprites and making 2D games? More to the point, does all this speed boost for 3D have any rollover to the 2D world that I live in? Will I get a speed boost too on my games?
  • 0

Button_DynamicPuddles_zps068ef8eb.png Button_Flappy_zps7fcff3b6.png Button_RogueLike_zps6f3451a3.png IKrQvWr.png Button_MyGames_zpse9e80bb0.png


#26 Manuel777

Manuel777

    InvaderGames

  • GMC Member
  • 3553 posts
  • Version:GM:Studio

Posted 05 May 2011 - 03:01 PM

Okay I am a 3D noob... BUT if a quad is a square or two triangles, isn´t that how GM deals with sprites? Two triangles textured from the sprite? And if so, then does my graphics card hate me for using sprites and making 2D games? More to the point, does all this speed boost for 3D have any rollover to the 2D world that I live in? Will I get a speed boost too on my games?

Nope, 3D and 2D are two very dirrefent things, you dont draw your sprites as textured poligons (thats what you have to do in 3D engines like Unity), in GM all 2D is really 2D, images stacked with different depths and effects, positioned over two axis, X nad Y, nothing more. Now when you go to 3D the things are hell of different, since you need a new axis ( Z ) all screen-position calculations are based on objects position in the world, the camera position, angles, etc. Plus you have to make sure objects dont mess up with other objects depth, you have to add shadows for every vertex in the models, normals.. etc etc etc..

Edited by manuel777, 05 May 2011 - 03:01 PM.

  • 0

#27 Medusar

Medusar

    GMC Member

  • GMC Member
  • 1228 posts
  • Version:GM:Studio

Posted 05 May 2011 - 03:10 PM


Okay I am a 3D noob... BUT if a quad is a square or two triangles, isn´t that how GM deals with sprites? Two triangles textured from the sprite? And if so, then does my graphics card hate me for using sprites and making 2D games? More to the point, does all this speed boost for 3D have any rollover to the 2D world that I live in? Will I get a speed boost too on my games?

Nope, 3D and 2D are two very dirrefent things, you dont draw your sprites as textured poligons (thats what you have to do in 3D engines like Unity), in GM all 2D is really 2D, images stacked with different depths and effects, positioned over two axis, X nad Y, nothing more. Now when you go to 3D the things are hell of different, since you need a new axis ( Z ) all screen-position calculations are based on objects position in the world, the camera position, angles, etc. Plus you have to make sure objects dont mess up with other objects depth, you have to add shadows for every vertex in the models, normals.. etc etc etc..

No, actually GM creates a D3D device regardless of 3D mode being on or not. That's why you can use the d3d_transform functions in 2D games. Enabling 3D mode just sets a couple of settings differently.

As for your question, Nocturne, I asked Mike that (don't recall where, must've been the other topic) and he said that the Delphi runner still draws sprites as individual quads. The C++ runner however puts sprites on a single texture page, so all drawing commands can be buffered by the runner and sent to the GPU all in one go.
  • 0

Posted Image

Q: Why do programmers always get Christmas and Halloween mixed up?
A: Because DEC 25 = OCT 31

#28 Nocturne

Nocturne

    Nocturne Games

  • Administrators
  • 23634 posts
  • Version:GM:Studio

Posted 05 May 2011 - 03:13 PM

As for your question, Nocturne, I asked Mike that (don't recall where, must've been the other topic) and he said that the Delphi runner still draws sprites as individual quads. The C++ runner however puts sprites on a single texture page, so all drawing commands can be buffered by the runner and sent to the GPU all in one go.


Thanks... so at the moment this advance will make no difference to me? At least not until the C++ runner is ready... Oh well. I am a patient man and can wait for GM9!
  • 0

Button_DynamicPuddles_zps068ef8eb.png Button_Flappy_zps7fcff3b6.png Button_RogueLike_zps6f3451a3.png IKrQvWr.png Button_MyGames_zpse9e80bb0.png


#29 Manuel777

Manuel777

    InvaderGames

  • GMC Member
  • 3553 posts
  • Version:GM:Studio

Posted 05 May 2011 - 05:16 PM

@Medusar: Really?? :huh:
Never knew that, i alway thought GM used a standard 2D drawing method..
  • 0

#30 Dark Matter

Dark Matter

    RPG Expert

  • GMC Member
  • 3196 posts
  • Version:GM:Studio

Posted 05 May 2011 - 05:39 PM


What are QUADS?

rectangles, squares, 2 triangles etc...

And that's different from drawing two triangles? How? How do you even do it, because I'm pretty sure you don't mean drawing two triangles is bad practice :P ?
  • 0
String Distortion (Now Staff Picked!)

The .gmx format disassembly

I'm always happy to help with a problem or question you have regarding Game Maker. Feel free to ask me anything you want!

#31 FredFredrickson

FredFredrickson

    Artist

  • Global Moderators
  • 9210 posts
  • Version:GM:Studio

Posted 05 May 2011 - 06:11 PM

You can do this currently to some extent, but you can't draw models with multiple textures in one larger model, so it's only useful for many objects that share the same texture, and often, those objects are not always going to be placed close enough together to take advantage of being grouped into a single model.

That's not true - the purpose of being able to combine multiple models into one and be able to add translations and transformations on the fly to the added models is to provide an alternate mechanism of an animated model - a vehicle or a character, for example. And having a single texture for those is mostly exactly what you'd want.

Edit: I already said that.

I think that we're both talking about different things here. I was looking at it from the point of a static model. IE - you divide up all the areas of your level into chunks that you draw / don't draw at certain places, and you use a function like this to draw large, texturally diverse areas at once. Static stuff only, not set up as some kind of animation hierarchy.

Of course, I'd love to see some kind of native 3D animation support / help added to Game Maker - even something basic. Not being able to easily animate groups of models in 3D is one of the main reasons why I haven't really done much with it in a while. It's incredibly discouraging to look at coding a (probably slow) animation engine for even simple games, when other game engines out there have that stuff built-in, ready to load up animations directly from your 3D software. (Before Mike sees this and thinks I'm trying to start a riot here!) I know Game Maker isn't headed towards this level of 3D support, and I don't expect it to... but some kind of options, even support for loading basic model file formats, would be nice.
  • 0

#32 YellowAfterlife

YellowAfterlife

    GMC Member

  • Global Moderators
  • 4114 posts
  • Version:GM:Studio

Posted 05 May 2011 - 06:49 PM

Nope, 3D and 2D are two very dirrefent things, you dont draw your sprites as textured poligons (thats what you have to do in 3D engines like Unity), in GM all 2D is really 2D, images stacked with different depths and effects, positioned over two axis, X nad Y, nothing more. Now when you go to 3D the things are hell of different, since you need a new axis ( Z ) all screen-position calculations are based on objects position in the world, the camera position, angles, etc. Plus you have to make sure objects dont mess up with other objects depth, you have to add shadows for every vertex in the models, normals.. etc etc etc..

Note: GameMaker's 2D layer seems to be rendered by standart 'textured polygon' methods as well - you can apply d3d transformations (and even ones that are not avaible for 2d matrixes, like rotating x, y, z axis at once) to it. Also, from practice, I can say that room backgrounds are being rendered by two for() loops instead of textured polygon (using 4x4 background image causes more lag than using 128x128 image with that same patern tiled).
  • 0
_.gifnDCITkv.png

#33 scream681

scream681

    Nick Larin

  • New Member
  • 1152 posts

Posted 05 May 2011 - 07:08 PM

General rules.

Draw as much as you can in a single draw call. This means put as much into a GM model as you can.

If you draw <1000 polys (more on larger systems), the CPU will get in the way, and the GPU will get bored and have an affair with your HardDisk and thereby slowing your game down even more. :P

The more you can draw, the more time your CPU will have to execute other game code. The CPU and GPU work in parallel with large models.

Skin your models - even buildings and terrain. This allows large sections of a world to be rendered in one go, rather than a brick at a time.

Never, ever, draw QUADS if you can possibly avoid it. Your graphics card WILL hate you.


Anything else.....?


I agree with all the above, and I really tried my best to optimize Darkverse in these areas, I even tried using DLLs to perform calculations and then draw the models. But the main issue of the 3D system seems to be the drawing speed itself. Its just incredibly slow.

I did some tests when optimizing the game and posted the results here: http://gmc.yoyogames...5

While I do perform a lot of draw calls probably more than 500 each step. The overall polycount is still extremely low for today standards (max 10000 tris). I tried performing tests on other engines with exactly same models and same amount of drawing calls resulting in 50-100 times faster rendering.

After long discussions and testing with a lot of people experienced with GM 3d and GM internal structure (including icuurd12b42 and Zach Reedy). I came to a conclusion that the draw calls themselves are slow, and no further GML optimization could be done.

I hope this proves helpful improving GM 3D. If you need any code examples or further information, contact me.

Nick.
  • 0

Posted Image


#34 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4465 posts
  • Version:GM:Studio

Posted 05 May 2011 - 09:37 PM

Maarten Baert: Yes that bugs been fixed. Should have been a looong time ago.

So yes. We draw ALL 2D using textured triangles, because thats what graphics cards do best. The Delphi runner is terrible for this, and because it draws quads has a real issue with the amount it actually draws. Not because the fill rate is reached, but because the number of draw calls kinda maxs out. If you imagine that each game has an upper most limit of draw calls (lets say about 5K)... you wouldn't be far wrong. Now, you can either draw 5K sprites, or 5K 3D models. The GFX card doesn't really care as drawing a quad is so quick, youd have been as well drawing 10K sprites in a single render instead.

The C++ runner "helps" the graphics card by putting lots of sprites on a single texture page, and when you draw sprites we build up a single vertex buffer with LOTS of sprites in a single batch. We can then draw LOTS of things in one go. This helps us stick to the 1st golden rule of rendering; render as much as you can in a single call. This isn't GML calls, it's DirectX DrawPrimitive() calls.

To give you an idea of just how powerful graphics cards are... GM 8.1 can probably draw around 10-15K (or so) obejcts at 30Hz(this is a guess BTW), but in C++ under "special" test conditions, I've rendered 1,000,000 sprites at 30fps. This was using a texture page, point sprites and some special shader code to render sprites from a T-PAGE. But it shows if you batch things into large batches, the Graphics card just gets on with it.

So yes. We render everything in triangles. It's faster. Drawing Quads is terrible. Sometimes you can't help it, and thats fine. But you should never render everything as single or double triangles, and thats exactly what GameMaker does. So yes Dark Matter; Drawing 2 triangles at a time is always bad, but sometimes you can't help it.


scream681: This should now be solved. You still don't want to render too many models, but you will certainly be able to up the polygon count well past what you currently do. This was the goal in the first place.
  • 0

#35 Desert Dog

Desert Dog

    GMC Member

  • GMC Elder
  • 6409 posts
  • Version:Unknown

Posted 05 May 2011 - 09:40 PM

As for your question, Nocturne, I asked Mike that (don't recall where, must've been the other topic) and he said that the Delphi runner still draws sprites as individual quads. The C++ runner however puts sprites on a single texture page, so all drawing commands can be buffered by the runner and sent to the GPU all in one go.


Quick, question concerning this. When making games, I don't go over 1024x1024, because games with large textures/images typically will get me players who can't run the game... they get an 'unexpected error' when loading is finished. Indeed, my computer struggles with large textures, too!!

What it sounds like here is we're going to end up with a pretty darn big increase in speed, but will older computers not be able to run it, because you've combined it all into 1 texture?


(note: 1024 is a base level I've personally set for myself as one all computers should be able to run, I believe the problem sizes are 2000+ sized textures)
  • 0
HTML5 games for mobile:
HexDogs Bugz Burn! Captain George Golfing Block Memory

Games for Androids
*NEW* Word Dog - Published by Dangerous_Dave


Code: General Array Functions - GM-S friendly. sorting, shuffling. Includes a quicksort.
Use the quicksort to sort ds_lists 10-18 times faster than ds_list_sort()!

#36 Nocturne

Nocturne

    Nocturne Games

  • Administrators
  • 23634 posts
  • Version:GM:Studio

Posted 05 May 2011 - 10:17 PM

As for your question, Nocturne, I asked Mike that (don't recall where, must've been the other topic) and he said that the Delphi runner still draws sprites as individual quads. The C++ runner however puts sprites on a single texture page, so all drawing commands can be buffered by the runner and sent to the GPU all in one go.


Quick, question concerning this. When making games, I don't go over 1024x1024, because games with large textures/images typically will get me players who can't run the game... they get an 'unexpected error' when loading is finished. Indeed, my computer struggles with large textures, too!!

What it sounds like here is we're going to end up with a pretty darn big increase in speed, but will older computers not be able to run it, because you've combined it all into 1 texture?


(note: 1024 is a base level I've personally set for myself as one all computers should be able to run, I believe the problem sizes are 2000+ sized textures)


Yes I wonder this too as I have experienced the same problem and even put the same size limit on my graphics (1024x1024 max)...
  • 0

Button_DynamicPuddles_zps068ef8eb.png Button_Flappy_zps7fcff3b6.png Button_RogueLike_zps6f3451a3.png IKrQvWr.png Button_MyGames_zpse9e80bb0.png


#37 nottud

nottud

    GMC Member

  • GMC Member
  • 130 posts

Posted 05 May 2011 - 10:53 PM

I have a wish relating to transformations - is it possible to add a command to save and load transformations of an object? So you say rotate a ball so much and then on the next draw you want to rotate the ball that amount plus a bit extra. This you could do by saving and transformation and then laoding it next step and adding another transformation. I know there is a stack but I can only save 1 transformation by that at a time really as it is a global stack. Is it possible to save a transformation to say like a variable or an index and laod them again for later use? Thanks.


  • 0

#38 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4465 posts
  • Version:GM:Studio

Posted 06 May 2011 - 06:32 AM

The largest texture size of older cards is usually 2048x2048. We currently targer 1K sizes on windows, but it's an easy change for us as we can actually target any size with ease.
  • 0

#39 Phantom107

Phantom107

    Graphics Enthusiast

  • GMC Member
  • 2714 posts
  • Version:GM:Studio

Posted 06 May 2011 - 08:10 AM

So yes. We render everything in triangles. It's faster. Drawing Quads is terrible. Sometimes you can't help it, and thats fine. But you should never render everything as single or double triangles, and thats exactly what GameMaker does. So yes Dark Matter; Drawing 2 triangles at a time is always bad, but sometimes you can't help it.

In GameMaker this is true, but for big 3D engines? No sir.

You see, quads aren't slow. It depends entirely on how it is programmed. Infact almost all effects, including particles, are based on quads. Modern games have thousands of particles going about, all quads!

The trick is this. Groups of particles are merged into a very small amount of primitives, as that will make them render very fast, just like any other model. Then they use realtime vertex manipulation on models to make the particles fly individually. If you can provide GM with functions to manipulate vertex data on the fly, quads won't be any problem whatsoever. Although then the bottleneck would be GML... but well, better than nothing. And there are more uses for it, like realtime deformation.
  • 0

GMCsig.png


#40 scream681

scream681

    Nick Larin

  • New Member
  • 1152 posts

Posted 06 May 2011 - 09:53 AM

scream681: This should now be solved. You still don't want to render too many models, but you will certainly be able to up the polygon count well past what you currently do. This was the goal in the first place.


I was never really bothered by the polycount. The game looks fine with the current meshes it uses. My main issue is the draw calls speed, will those be faster? Rendering more polys helps when you got static levels, but when you have lots of things moving on the screen, you can't avoid numerous draw calls.
  • 0

Posted Image


#41 Arial

Arial

    GMC Member

  • Banned Users
  • 580 posts
  • Version:GM8

Posted 06 May 2011 - 11:13 AM

There are lots of solutions in the 3D section to save FPS. Note that all the discussion is about more frames per second and not about saving loading time.

please make a topic about loading time reduction or give some possible solution or sample

i use global.model to speed up FPS but the loading time increases sometimes i wait for 15 minutes for the game to run.I noticed with the option global.model or global.texture the loading time takes longer.

For me the biggest concern now is loading time. Then i promise you i will produce something with GM that is close to SplinterCell.

Edited by Arial, 06 May 2011 - 11:17 AM.

Screw everyone who puts my quotes in his signature to make fun out of me.

#42 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4465 posts
  • Version:GM:Studio

Posted 06 May 2011 - 11:21 AM

In GameMaker this is true, but for big 3D engines? No sir.


Sorry, thats just wrong. Large 3D engines (and I've written a few!) don't render QUADs unless they have to. Things like particles are batched into "dynamic" vertex buffers. This means we go through and add a QUADs in world space into the buffer, then when a renderstate changes (blend mode, texture etc.) then the last batch is submitted. This avoids the issue of having to draw 20,000 QUADs. D3D and graphics card DO not like doing this.

I'll say this again, graphics cards WANT to draw 20,000 triangles (well..large numbers of polys). graphics card dev support gets VERY upset if you complain a game is slow, and they discover your drawing 2 or 3 polys at a time.

What your getting confused over is the difference between static and dynamic vertex buffers. Static buffers are ones you create, and then never change. Dynamic buffers are ones you can create each frame, but these tend to be about a third the speed of static ones. But... you ALWAYS batch things if you can, and certainly with particles etc. you HAVE to. Oh...and GameMaker doesn't even use proper Dynamic buffers either... :(

If you want to see the history of this... you USED to submit individual triangles, back in DX5 and DX6 days. Then we moved onto tri-strips (still DX6 days). When DX7 came out, we had hardware T&L for the 1st time, and at this point, this rule came into effect. To get the best from it, you had to batch render using vertex buffers, and we had to get used to static/dynamic models. Before this, there was ONLY dynamic meshes, because everything was submitted by the CPU a triangle or 2 at a time.

So really... trust me. You DON'T ever want to submit quads if you can possibly avoid it. Some times you can't help it... but a lot of the times you can.

As to draw call speed. it should be faster as the CPU will now not spend AGES making the models over and over again, it just throws it very quickly at D3D and returns. So should be better all round.


EDIT: Arial: Model Loading time is nothing to do with us... it's up to the extension. We won't be changing loading time that much, and to be honest most of it is in Audio setup, and it stalls inside DirectX Sound initialisation, which is again nothing to do with us; it's driver related.
  • 3

#43 Phantom107

Phantom107

    Graphics Enthusiast

  • GMC Member
  • 2714 posts
  • Version:GM:Studio

Posted 06 May 2011 - 11:25 AM

OK, thanks for the explanation. I'm going to compare what you said to the documents on nVidia Developer Zone. If I don't reply to this matter then it's good.
  • 0

GMCsig.png


#44 Arial

Arial

    GMC Member

  • Banned Users
  • 580 posts
  • Version:GM8

Posted 06 May 2011 - 11:27 AM

As to draw call speed. it should be faster as the CPU will now not spend AGES making the models over and over again, it just throws it very quickly at D3D and returns. So should be better all round.

Yeah but waiting 15 minutes to load my resident evil 4 clone with the same 3d models used in resident evil 4? While loading the original resident evil 4 takes only 2 minutes.

Please take this loading time issue also serious. Thanks

Edit: Sorry for my bad english. I try to explain the solution to this problem....To throw the d3d model like that without having to load it over and over. Then you have a better gamemaking program then Unity, Shiva and all the ohter non offerdable engines.

Edited by Arial, 06 May 2011 - 11:47 AM.

Screw everyone who puts my quotes in his signature to make fun out of me.

#45 Aragon

Aragon

    GMC Member

  • GMC Member
  • 142 posts

Posted 06 May 2011 - 02:06 PM

What is the problem of loading time? Just add a loading screen and thats all, people just have to wait. In the intro of your game you could really load 30% of the whole game, so I don't see the problem. And using models of 2mb is way to much for GM because it can't handle the models.

My biggest suggestion, add frustum culling not only backwards-culling it will save a lot, and create LOD system.
  • 0

#46 Arial

Arial

    GMC Member

  • Banned Users
  • 580 posts
  • Version:GM8

Posted 06 May 2011 - 02:43 PM

And using models of 2mb is way to much for GM because it can't handle the models.

Today you have proven that you do not try to clone 3d games like splinter cell or resident evil.
And for sure you do not experiment with real good looking 3d models in gm8.1.

I have 3d models of 0mb which lower the fps of older gm version. You know why it was 0mb because I made the model very small so the computer gave 0mb file size. But the polygons stay the same. So if a 2mb impressive model of splinter cell is 200000 poly. When file size is reduced to 0mb the poly is still 200000. So it is not about file size of the model but about polygons and vertex and quads.

But for you to wake up the isseu of frames per second was solved whith the release of gm8.1. Trust me I experiment everyday with 3d models in gm. The frames per second produced in gm8.1 are reasonable speed.

The only major problem remaining is that the loading time is to much it should be at least 3x faster. Imagine you buy resident evil 6 but when you try to load and wait almost 20 minutes I think you will take cd out and never play it again.

Edited by Arial, 06 May 2011 - 02:46 PM.

Screw everyone who puts my quotes in his signature to make fun out of me.

#47 scream681

scream681

    Nick Larin

  • New Member
  • 1152 posts

Posted 06 May 2011 - 02:47 PM



As to draw call speed. it should be faster as the CPU will now not spend AGES making the models over and over again, it just throws it very quickly at D3D and returns. So should be better all round.

Yeah but waiting 15 minutes to load my resident evil 4 clone with the same 3d models used in resident evil 4? While loading the original resident evil 4 takes only 2 minutes.

Please take this loading time issue also serious. Thanks

Edit: Sorry for my bad english. I try to explain the solution to this problem....To throw the d3d model like that without having to load it over and over. Then you have a better gamemaking program then Unity, Shiva and all the ohter non offerdable engines.


There is no way GM would be able to handle Resident Evil 4 graphics, I'm surprised it loads at all... And loading models is the least of the issues you will encounter. You are talking about things GM was never intended for (or not yet at least).
  • 0

Posted Image


#48 Arial

Arial

    GMC Member

  • Banned Users
  • 580 posts
  • Version:GM8

Posted 06 May 2011 - 02:51 PM

There is no way GM would be able to handle Resident Evil 4 graphics, I'm surprised it loads at all... And loading models is the least of the issues you will encounter. You are talking about things GM was never intended for (or not yet at least).

WTF? Did you ever tried to run a ripped model of resident 4 in gm? If no please do it. Then you will see the truth capabilty of GM. Some guys are brainwashed and believe what others say. And blindling you will not try out if gm can run impressive 3D models.

Edit: please try out something before you reject it

Edited by Arial, 06 May 2011 - 02:53 PM.

Screw everyone who puts my quotes in his signature to make fun out of me.

#49 Aragon

Aragon

    GMC Member

  • GMC Member
  • 142 posts

Posted 06 May 2011 - 02:56 PM


And using models of 2mb is way to much for GM because it can't handle the models.

Today you have proven that you do not try to clone 3d games like splinter cell or resident evil.
And for sure you do not experiment with real good looking 3d models in gm8.1.

I have 3d models of 0mb which lower the fps of older gm version. You know why it was 0mb because I made the model very small so the computer gave 0mb file size. But the polygons stay the same. So if a 2mb impressive model of splinter cell is 200000 poly. When file size is reduced to 0mb the poly is still 200000. So it is not about file size of the model but about polygons and vertex and quads.

But for you to wake up the isseu of frames per second was solved whith the release of gm8.1. Trust me I experiment everyday with 3d models in gm. The frames per second produced in gm8.1 are reasonable speed.

The only major problem remaining is that the loading time is to much it should be at least 3x faster. Imagine you buy resident evil 6 but when you try to load and wait almost 20 minutes I think you will take cd out and never play it again.

Today i will show you a pic of my 3D online fps

http://g2f.nl/1705f1
http://g2f.nl/jhsa0n [just the blood haha old pic]
Yes it is made with u3d not the normally D3D. Oké your right it is not about the size of the file, but just create the model before your ingame, It is the same method, in U3D i've got the same problems either but i've loaded and create the models before joining the game just a simple code like this could help it:

if start_game=false{
draw_sprite(0,0,spr_wholescreen)
draw_text(display_get_width()/2,display_get_height()/2,"Loading")
}
and after you load/create everything set start_game to false, and play.
Oké thats just to simple i know the have to be some other codes but it isn't that bad...
Besides this topic is about coding the new 3D system, not complaining about loading time. Of course is should be faster but i think you have to wait about that. There a bunch of things that have to be done!

Edited by Aragon, 06 May 2011 - 03:00 PM.

  • 0

#50 Arial

Arial

    GMC Member

  • Banned Users
  • 580 posts
  • Version:GM8

Posted 06 May 2011 - 03:10 PM



And using models of 2mb is way to much for GM because it can't handle the models.

Today you have proven that you do not try to clone 3d games like splinter cell or resident evil.
And for sure you do not experiment with real good looking 3d models in gm8.1.

I have 3d models of 0mb which lower the fps of older gm version. You know why it was 0mb because I made the model very small so the computer gave 0mb file size. But the polygons stay the same. So if a 2mb impressive model of splinter cell is 200000 poly. When file size is reduced to 0mb the poly is still 200000. So it is not about file size of the model but about polygons and vertex and quads.

But for you to wake up the isseu of frames per second was solved whith the release of gm8.1. Trust me I experiment everyday with 3d models in gm. The frames per second produced in gm8.1 are reasonable speed.

The only major problem remaining is that the loading time is to much it should be at least 3x faster. Imagine you buy resident evil 6 but when you try to load and wait almost 20 minutes I think you will take cd out and never play it again.

Today i will show you a pic of my 3D online fps

http://g2f.nl/1705f1
http://g2f.nl/jhsa0n [just the blood haha old pic]
Yes it is made with u3d not the normally D3D. Oké your right it is not about the size of the file, but just create the model before your ingame, It is the same method, in U3D i've got the same problems either but i've loaded and create the models before joining the game just a simple code like this could help it:

if start_game=false{
draw_sprite(0,0,spr_wholescreen)
draw_text(display_get_width()/2,display_get_height()/2,"Loading")
}
and after you load/create everything set start_game to false, and play.
Oké thats just to simple i know the have to be some other codes but it isn't that bad...
Besides this topic is about coding the new 3D system, not complaining about loading time. Of course is should be faster but i think you have to wait about that. There a bunch of things that have to be done!

Like the pics cannot open.

We all know lots of things are missing in gm8.1 regarding 3d programming for example very importend animations as Phantom107 mentioned. But whats the point to fix the small bugs and add other functions even if they are importend, when the base is wrong.

With base I mean the start up. Start up is the first thing what happens in a game. And if the user gets angry at the start up and trows the game away then you have failed. If you have to wait almost 20 minutes to load a good looking game there is no need to add new futures in gm and fix the bugs.

I know if I play game it has to load quickly, but if it takes longer then 3 minutes I may give up.
Anyone wanting to wait almost 20 minutes or more for a game to load?

Edited by Arial, 06 May 2011 - 03:19 PM.

Screw everyone who puts my quotes in his signature to make fun out of me.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users