Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Matrix's are slow..?

Author
Message
bob_marley
16
Years of Service
User Offline
Joined: 19th Sep 2007
Location:
Posted: 6th Jan 2008 21:11 Edited at: 8th Jan 2008 00:55
Once upon a time i reads somewhere that matrix's are slow and "bad"

something about dbpro drawing every polygon no matter on distance

i was wondering if any one can confirm it?

shame if they are i suppose i could make a matrix from an object but it sounds like hard work which should be avoided

would make collision easier tho

http://forum.thegamecreators.com/?m=forum_view&t=121141&b=6

simple editable text boxes..
andrey d
16
Years of Service
User Offline
Joined: 30th Jun 2007
Location:
Posted: 6th Jan 2008 22:28
It uses too many polygons, as do all the primitives. Just load in your own, substitute a plain for the matrix and you'll be fine.
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 6th Jan 2008 23:26
They are slow because they don't have any face indecies/welded verts(though each separate tile may), however this isn't so much of a problem, but a limitation of the way matrices work because they use a single texture sliced up and shift the UV data for the verts on each tile. If they were all welded you couldn't have such tiling, or at least it wouldn't work 99% of the time.

You can however create a terrain which has all overlapping verts welded and achieve the same texturing method a matrix uses, but this would require a shader.

bob_marley
16
Years of Service
User Offline
Joined: 19th Sep 2007
Location:
Posted: 7th Jan 2008 00:52 Edited at: 7th Jan 2008 00:54
thanks for replies guys

@andrey - do you mean one plain or loads to simulate a matrix?

@darkcode - i am so very close to grasping what you just said, oh so close but not quite? :-|

p.s yay i can post straight away now, must celebrate

http://forum.thegamecreators.com/?m=forum_view&t=121141&b=6

simple editable text boxes..
Mr Tank
21
Years of Service
User Offline
Joined: 25th Nov 2002
Location: United Kingdom
Posted: 7th Jan 2008 00:57
Dark Coder-

I though that was the way all meshes worked in DB now. At least, that's the impression i get from the current memblock format: each triangle has three unique vertices that are not shared with any other triangle, and each vertex has unique normal and uv coordinates. Therefore there are (for an infinite matrix), 6 times more vertices than you need.

I seem to remember the old memblock format had a list of vertices (numbered), followed by a list of triangles referring to vertices by number, which would seem more logical.

Maybe .x or other objects loaded may use vertices actually shared between triangles? This would be interesting to know more about- perhaps by exporting in the right object format i can speed up my game.

Also, i'd be interested in knowing whether a memblock terrain might be any faster than db matrices. I'd want pretty much the same functionality (ie independantly texturable tiles)

One thing i do know- if you position your matrix, it now automatically updates it.

SUPER BADASS SPACESHIP X: WEBSITE
FORUM TOPIC
Sid Sinister
18
Years of Service
User Offline
Joined: 10th Jul 2005
Location:
Posted: 7th Jan 2008 01:30
Quote: "They are slow because they don't have any face indecies/welded verts(though each separate tile may), however this isn't so much of a problem, but a limitation of the way matrices work because they use a single texture sliced up and shift the UV data for the verts on each tile. If they were all welded you couldn't have such tiling, or at least it wouldn't work 99% of the time."


Woah, don't think so.

Wielding verts doesn't necessarily affect FPS directly, but it does save memory because your using a smaller size memblock in the end. By wielding vertices, your cutting out 2/3 the amount of vertices over all. You can still have individually textured tiles if you weild vertex's, as each set has it's own UV data.

Quote: "Also, i'd be interested in knowing whether a memblock terrain might be any faster than db matrices"


I'm confused on this as well. In my opinion, memblock matrices are better for reasons I'll touch on next, but the speed of them isn't that great. But maybe I'm not doing something right.

In the fight against DB Matrices and Memblock Matrices, I think, in the end, memblock matrices win, mainly because you can do a ton more stuff with them than DB Matrices.

Want culling? Make each tile in a memblock matrix a limb.

Want to be able to treat your terrain as an object? Convert memblock to mesh, convert mesh to object.

Want to be able to edit the X and Z position on a matrix and not just the Y?

There are just so many uses for it. Memblock terrains are harder to program, but there are a few good examples around here showing different things. Check the codebase especially - search memblock and you should find a memblock terrain example.

I have yet to unlock the speed of these beasts, but... then again I just learned how do this stuff last week so, I'm relatively new with memblock matrices.
bob_marley
16
Years of Service
User Offline
Joined: 19th Sep 2007
Location:
Posted: 7th Jan 2008 03:07
would just using an object as terrain be any good?

ie an ordinairy .x

in terms of functionality i would say so...

but in terms of speed i dont know...

heh i made a ryhme

http://forum.thegamecreators.com/?m=forum_view&t=121141&b=6

simple editable text boxes..
andrey d
16
Years of Service
User Offline
Joined: 30th Jun 2007
Location:
Posted: 7th Jan 2008 05:08
For what do you want to use a matrix? I'll understand what you want better.
jeffhuys
17
Years of Service
User Offline
Joined: 24th May 2006
Location: No cheesy line here.
Posted: 7th Jan 2008 08:20
I think he means to use it as a terrain, then I would take a look at Advanced Terrain.

-Jeff


You're the 'th to view this signature!
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 7th Jan 2008 08:25
Quote: "You can still have individually textured tiles if you weild vertex's, as each set has it's own UV data. "


Nah, wouldn't work. To weld properly you have to have 2 vertices's exactly the same, same position and same UV coordinates. To give a polygon different UV coords from neighboring polygons you need unique vertices's. I prefer avoiding tiled style matrices, I use a terrain object and mould the vertices's to suit a heightmap, the UV's just depend on the actual 3D X and Z location so welding is not a problem - the actual texturing is done with a shader and mask images.


less is more, but if less is more how you keeping score?
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 7th Jan 2008 08:30 Edited at: 7th Jan 2008 08:34
Quote: "Wielding verts doesn't necessarily affect FPS directly"


Yes it does. Less verts = less transformations = more FPS.

Quote: "but it does save memory because your using a smaller size memblock in the end."


No. The memblock regardless of how many welds you use(in DBP at least) will result in the exact same memblock size every time, no exceptions. This is because(unless I'm very mistaken) if you create a memblock mesh with 300 verts you end up with 100 tris, but you then only have access to 300 sets of index data(100 tris), you cannot arbitrarily add index data.

Quote: "You can still have individually textured tiles if you weild vertex's, as each set has it's own UV data. "


No you cannot, for example let's say I'm looking at tile 2,2 and I have fully welded all overlapping verts, this means my current tile already has UV data as the 8 surrounding tiles will be fighting over which verts have their UV data, for this reason unless your terrain looks like an AT one(i.e. all the UV data is contiguous) it will look very messed up.

The main speed loss with matrices opposed to Advanced Terrains is that matrices are a single object, because of this frustum culling for the most part doesn't have any affect, if you split up your matrix by using many of them, similar to how ATs work(though they use limbs) you should in theory get higher FPS(than standard matrices).

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 7th Jan 2008 08:40
I'm not sure if you can even 'weld' in a memblock - I think you'd have to make your terrain from a memblock then use the vertex commands to weld shared vertices, there's a code snippet around somewhere that does that.


less is more, but if less is more how you keeping score?
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 7th Jan 2008 08:44
Quote: "I'm not sure if you can even 'weld' in a memblock - I think you'd have to make your terrain from a memblock then use the vertex commands to weld shared vertices"


This is correct, though from what I'm told DBC has index data written in the memblock; wonder why this was removed.

bob_marley
16
Years of Service
User Offline
Joined: 19th Sep 2007
Location:
Posted: 7th Jan 2008 12:51
yeh i want it for terrain

but the catch is i want so i can change it ie move vertex's slightly and down

can advanced terrain do this?..feasibly

actually better question how roughly does advanced terrain work?
what does it do

i'd also like to thank you all for your time answering my many questions

http://forum.thegamecreators.com/?m=forum_view&t=121141&b=6

simple editable text boxes..
Sid Sinister
18
Years of Service
User Offline
Joined: 10th Jul 2005
Location:
Posted: 7th Jan 2008 18:55
Sorry, was working on some bad information I guess.

Why wouldn't the memblock be smaller though? If your removing verts from the index... why wouldn't the size be smaller? When you mess with the index, don't you end up deleting the old memblock and then make a new memblock with the new amount of verts from the edited index? I have it done it myself, I'm trying to remember the code I saw.

Quote: "Yes it does. Less verts = less transformations = more FPS."


Kinda what I meant by, 'not directly.' Along with that I did mean because less memory is being taken up by the memblock, but apparently I'm wrong about that.


Quote: "I prefer avoiding tiled style matrices, I use a terrain object and mould the vertices's to suit a heightmap, the UV's just depend on the actual 3D X and Z location so welding is not a problem - the actual texturing is done with a shader and mask images."


So wait... how does having vertices positioned around your terrain in a grid style, differ from having tiles? And your not texturing the polygons? Your using a shader and mask images? Is this with Green Gandalfs stuff?

Man... if what you say is true, I might just scrap what I'm doing over in my heightmap brush thread I've been working in.

I've made a memblock matrix with tiles in it but it's slow. I was going to make each tile a limb and cull to make it faster. But if what you described above is how your doing your level editor, and it's faster, I might just switch.

But I want to know how your grid of verts differs from tiles... as in... how do you create your grid of verts without making tiles at the same time? Or do you o.0 lol.
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 7th Jan 2008 20:49
Ahh, bad choice of words on my part. When I said tiled, I meant the actual texturing, like each section can have it's own texture just like a matrix.
I use one of Green Gandalf's shaders, then use mask images to specify amounts of each texture for each part of the terrain. The mask images can be the same resolution as the terrain, but as it's an image it can be bigger or even smaller than your terrain. I use a double resolution to give things a smoother look.


less is more, but if less is more how you keeping score?
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 7th Jan 2008 23:32
Quote: "Why wouldn't the memblock be smaller though? If your removing verts from the index... why wouldn't the size be smaller?"


Because like I said to create 100 triangles you must create a memblock with 300 vertices, once done you can later make these 100 triangles use less verts via the vertex indices, however the original memblock you used to create the memblock mesh will not have differed.

Quote: "because less memory is being taken up by the memblock, but apparently I'm wrong about that."


It's entirely possible that it uses less GPU RAM, and only sends information about all verts that are referenced via the index data, however that in itself could be slower to calculate, and for most cases the reduction in vertex data would be very minimal compared to any texture data you store on a GPU, plus when you make a memblock from a mesh from an object that had index data, you get the original memblock and not a reduced one with only referenced verts.

In DBP there are currently 4 main(popular) ways to create terrains, the first is the matrix approach, where your terrain is textured by a single image, and you essentially slice this image up and shift the UV data for each tile to make it appear as if each tile uses many images. The advantage to this method is that each tile can be very different and highly detailed, the down side is that you cannot weld all overlapping verts so it's usually slower than other methods, and any transitions between tiles must be done yourself. You can make a variant of this using shaders that has fully welded verts, however this has potential to be slower on lower end cards, but I've yet to test this.

Another method is to have a fully welded mesh but store up to 7 layer opacity values per vertex, then texture the terrain with 8 images, multiplying the new layer with the opacity value for that layer then adding it. The advantage to this method is that you can have a sand texture at the shores as well as grass on the land and they will automatically blend smoothly, however if you have 8 textures you're sampling 8 textures per pixel and doing 7 multiplications and additions which could get slow. Plus each vertex requires 7 bytes to store alpha values in(which isn't much of an issue).

The third method is similar to the above one only you use images to store the alpha values of each texture layer, this is both good and bad as it allows you to specify the alpha precision of each layer, so you can have higher resolution alpha detail than per vertex, but unless you use a texture atlas you're limited to 4 layers(including the base). Also for only 3 additional layers(excluding the base) you're doing 6 texture lookups per pixel, so it's probably better to use the 2nd option.

And of course Advanced Terrains use a different method too, they have two layers, one is a highly tiled detail map, with a colour map on top which stretches over the whole terrain, this is probably the fastest method out of the others. However colour maps are highly limited as you're only really changing the colour of the detail map, you cannot have a sand texture at the beaches and a grass texture on the land, only a generic ground texture tinted yellow at the beaches and the same tinted green on the land.

Sid Sinister
18
Years of Service
User Offline
Joined: 10th Jul 2005
Location:
Posted: 8th Jan 2008 00:53
Quote: "Another method is to have a fully welded mesh but store up to 7 layer opacity values per vertex, then texture the terrain with 8 images, multiplying the new layer with the opacity value for that layer then adding it. The advantage to this method is that you can have a sand texture at the shores as well as grass on the land and they will automatically blend smoothly, however if you have 8 textures you're sampling 8 textures per pixel and doing 7 multiplications and additions which could get slow. Plus each vertex requires 7 bytes to store alpha values in(which isn't much of an issue)."


It sounds like I'm using the first option using a memblock matrix, but you have me very interested in this second (above quote) way. Know of any threads detailing this procedure further? Would green gandalf's ultimate shader thread be one?
bob_marley
16
Years of Service
User Offline
Joined: 19th Sep 2007
Location:
Posted: 8th Jan 2008 00:53 Edited at: 8th Jan 2008 00:58
cheers dc that shed a lot of light on this subject even for a simpleton like me, cheers

p.s i agree with sid is there any examples or tutorials?

edited: because i dont know how to spell

http://forum.thegamecreators.com/?m=forum_view&t=121141&b=6

simple editable text boxes..
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 8th Jan 2008 01:06
Quote: "Know of any threads detailing this procedure further? Would green gandalf's ultimate shader thread be one?"


I believe I read somewhere that GreenGandalf made a shader that does this, but I haven't looked into it. However this doesn't require a shader as 3DWS exported terrains are capable of the same thing, though it may be slower?

I'll see if I can make an example of 2 and 3.

bob_marley
16
Years of Service
User Offline
Joined: 19th Sep 2007
Location:
Posted: 8th Jan 2008 02:42
Quote: "I'll see if I can make an example of 2 and 3.
"

that'd be swell i'll have to credit you and all the other helpfull people, learn lots in these forum's so i do

http://forum.thegamecreators.com/?m=forum_view&t=121141&b=6

simple editable text boxes..
Sid Sinister
18
Years of Service
User Offline
Joined: 10th Jul 2005
Location:
Posted: 8th Jan 2008 03:00
Oooh. I'd like that =]

Login to post a reply

Server time is: 2024-05-17 04:04:01
Your offset time is: 2024-05-17 04:04:01