Single Mesh?

Blitz3D Forums/Blitz3D Programming/Single Mesh?

dmaz	(Posted 2004) [#1]

Before I test it myself... I'm creating a single surface particle/fx system and as I understand it, you still need a separate surface for every texture. I was wondering if anybody knows if it's better to create 1 mesh with many surfaces(1 for each texture) or have 1 mesh for each surface? Also, can you think of any reason why, outside of speed that one way would be better than the other?

thanks

Rob Farley

(Posted 2004) [#2]

You don't need a new surface for each textures, there's no reason why you don't dump all the different particles onto on textures (surface) and use the UV co-ords to pick the right one.

However, there is a trade off eventually when you've got so many triangles on one surface it starts getting slow.

This is why you need to start splitting into different surfaces.

Personally I'd go with 1 surface per emitter, it seems to make sense to me as the auto culling blitz does should work well as you're not going to have 1 entity spread over a massive area.

dmaz	(Posted 2004) [#3]

I just thought of something that I haven't seen in many other particle systems. If I'm able to keep all my textures the same size then I should be able to use LoadAnimTexture. With that would only have 1 surface and while doing my UpdatePartcles() I wouldn't have any texture switch on the video card which I understand can also be costly... Does this sound right?

dmaz	(Posted 2004) [#4]

Thanks Rob. Do you have an idea as to why many triangles on a surface start to slow it down as apposed to have the same number of tris on multiple surfaces?

dmaz	(Posted 2004) [#5]

Rob, would you have multiples meshes in the case you describe?

dmaz	(Posted 2004) [#6]

Using your method vs the LoadAnimTexture would also be better because then I could have different sized textures as well... just a little more programming. Thanks Rob.

So then on that note, anybody know of a program that can display the proper UV coords for texture postitioning or routine where you put in the x/y pixel offsets and the height/width?

AdrianT

(Posted 2004) [#7]

don't know if it would be any faster but you coudl probably map your textures onto a single tri rather than use quads, if you made your particles yourself and halve the polycount. Unless blitz draws quads faster than tris.

dmaz	(Posted 2004) [#8]

Yeah, the system i'm making does use tris. It also uses quads in the shape of square or dimonds. Also the vertexes can be deformed for certain effects.

I found (on my card at least) that tris, even with the larger fill, are a little faster than quads.

Rob Farley

(Posted 2004) [#9]

Thanks Rob. Do you have an idea as to why many triangles on a surface start to slow it down as apposed to have the same number of tris on multiple surfaces?

No, I know you have only have 65k verts per surface, but it's a matter of balance, I'm sure someone like sswift will give you all the reasons why though, I think it's something to do with the cost of rebuilding a mesh every update or something.

Rob, would you have multiples meshes in the case you describe?

Yes, a new mesh for each emitter. This is a good idea in my opinion as if an emitter is behind the camera the particle mesh won't be rendererd, however, if all your particles are in the same mesh all the particles will be rendered regardless of if they are in view or not.

So then on that note, anybody know of a program that can display the proper UV coords for texture postitioning or routine where you put in the x/y pixel offsets and the height/width?

That's pretty straight forward, a UV co-ord goes from 0-1 so if your texture is 512x512 512=1 and 0=0 so .5=256, .25=128 etc etc, very simple.

don't know if it would be any faster but you coudl probably map your textures onto a single tri rather than use quads

Again it's a balancing act (varying from card to card), personally I'd stick to quads as it make UV mapping a hell of a lot easier. Unless you're talking about 100,000s of particles I don't think on modern cards your really going to make that much difference. Triangle count isn't really the problem here.

jfk EO-11110

(Posted 2004) [#10]

Not sure if it was already mentioned, but if your mesh is not loaded with LoadAnimMEsh (and I assume it isn't, it's rather created at runtime, right?) and if it has mutliple Surfaces, it will be rendered completely, even if only one surface is in the FOV of the camera. But if you have a mesh per surface, fustrum culling will skip rendering of any mesh that isnt in the FOV of the camera.

N	(Posted 2004) [#11]

In Lotus R2 I can manage 8,000 particles (that'd be about 16,000 triangles), so there's a rough estimate of what you can aim for.

dmaz	(Posted 2004) [#12]

With all cases? Someone posted that if you make 2 vertices of a tri the same, that tri won't be rendered at all. I use this now in my current quad system and it does seem to be the case.

That's pretty straight forward, a UV co-ord goes from 0-1 so if your texture is 512x512 512=1 and 0=0 so .5=256, .25=128 etc etc, very simple.

Yeah thanks, I wasn't thinking.

I'm using both quads and tris. I already have the UVs all setup on the tris, they do allow the fps to stay a little higher...

dmaz	(Posted 2004) [#13]

yeah with this information and Rob suggestions I'm going to go with 1 mesh per surface. Not per emitter in my case for 2 reasons; most of my emitters will be on screen at the same time and I want to keep the surface count low cause that does seem to be the biggest hit.

Thanks everybody.

dmaz	(Posted 2004) [#14]

Noel, you have a great engine. I'm not using it here only for a few reasons. no docs yet (It supports a lot of stuff) and it doesn't tween (yours should do this). Also there are a few other fx that I wanted to do.

Now about your numbers... what do you mean by "manage"? How many would you have on screen at that time?