Model classifications.
There are 2 different kinds of models; static and dynamic. Dynamic models are models that you create each frame, where as static ones are models you make once, then never touch them again - except to draw them.
Up until now, GameMaker has only ever used dynamic models, even for models where you use d3d_model_create(). In fact, all d3d_model_create() did was to allow you to pre-generate the primitives you would be using; nothing more. On top of this was the method of actually using D3D, which wasn't efficient either. All this added up to a slow use of the graphics card.
GameMaker 8.1 introduced full Hardware transform and lighting, but this has brought in a couple of new restrictions in exchange for the speed boost it'll give. First, DirectX8 hardware only allows for 8 lights, any more and you'll get unpredictable results - or none at all. But this just means you've to manage the lights yourself which isn't hard. Hardware T&L gives you a nice little boost on its own, but drawing quads (2 triangles at a time) isn't what modern hardware wants. It wants large batches, the larger the better. And this beings me onto the next speed boost.
Static Models.
The next update will introduce true static models; models you make at start-up and then just draw. The new system takes GameMaker models and then generates full hardware based, static VertexBuffers the first time you try and draw them. What this does is provides the hardware with exactly what it wants for rendering, a large buffer full of primitives. This new system allows you to up the number of primitives per model to tens or even hundreds of thousands of polygons per model. Unlike dynamic models, the more polys you have in a mesh the more you let a graphics card can do its thing.
The picture above shows the new faster system, and it shows it can now draw a 19,683 cubes merged into a single 236,196 polygon mesh at 96fps rather than 4! This is a significant boost, but to achieve this, you need to follow a couple of new rules...
Draw as much as you can in a single model call. Every time you stop rendering to do something else, the CPU gets in the way and the GPU gets bored!
Don't change the draw_set_color() of the mesh if you can help it. If you only need (say) the same mesh but drawn in 2 colours, then make more the model twice.
Your probably better drawing 5,000 polys as to 2.
Lastly.... this "batching" DOES change the order of things. It will batch triangles, lines and points together, and this means if for some reason you draw a triangle, a line then another triangle... the result MAY be different from what it was before as we now draw ALL triangles, then ALL lines, then ALL points. If this is the case, and you NEED the previous result, then you should probably draw it as a dynamic model instead; i.e. don't use d3d_model_create().
7 Smart arse replys:
This is excellent Mike. I'm also pumped for the 3d surface fix. Some other things come to mind which could drastically improve 3d in GM.
I can think of a few really big ones but let's go with something easier to implement at the moment. Mouse picking, texture filtering, and anti-aliasing.
3d picking is one of the most asked for functions in one form or another.
Texture filtering is a matter of switching it on. The filtering that GM currently does is very bad and even worse in 3d.
Anti-aliasing requires a little more setup but it could make a world of difference, and it could also be beneficial in 2d, for rotating primitives or drawing lines for that matter.
All my assumptions are based upon my own experiences with DirectX 9 and 10 using C++. All three of these suggestions are easily feasible in the provided environment. I would imagine it's not to different with Delphi and DirectX 8, but I wouldn't know for sure. I can provide examples and source code upon request if you'd like.
Wait when Knuked says there will be a 3D surface fix does that mean surfaces will soon work in 3D mode. I hope so because then I won't have to use the surfacefix DLL on my current game.
I'm glad to see 3D sped up. If you add a few more 3D features GameMaker's 3D system will actually be a good option for beginning 3D developers. Not because it's any better--its not--but because of the easy to use GML.
@Mr. Me: Yes, Mike sent me a PM and he is planning on natively fixing 3D surface support. If he gets it working (which he hopefully will), then you won't need my DLL anymore.
Thanks for the clarification Amd42, I just assumed that's what grand master Mike was referring to. Here's to hoping it goes well :)
Very groovy. Many have been crying out for a 3D speed boost, so this will bring smiles to alotta faces. I'm wondering if there are any plans to better integrate 3D game creation in general into GM? Since it's been added, 3D has remained something of a mysterious part of GM to many "non-coder types". The 3D functions exist as code only (no drag & drop) & even simple things like model rotations are fiddly because of the required translations (I've seen many instances where those trying to create a 3D game have let it drop once this kind of thing complicates things for them), & setting up the most basic things required for a 3D game (like cameras) have been a stumbling block for many. Are there any plans to eventually address this & make 3D game creation more accessible? Might we ever see things like D&D buttons for the most common cam set-ups (1st person, 3rd person, side view, top down)? Or a 3D room editor? Or rot/scales at origin of the object? Even just including examples that went through the most common set-ups would be of massive help to people I think, & result in many more great 3D games coming out.
Anyway, I can see a big surge in interest in & attempts to make 3D games once this speed boost is announced! Amazing work!
There are some news about next update Mike?
This is not stricly on topic, but is drawing antialiased polygons supposed to work on surfaces, or only when drawing directly to the screen? Could be just my hardware, but anything drawn on a surface looks always non-antialiased.
Post a Comment