couple of silly B3D questions...
Blitz3D Forums/Blitz3D Programming/couple of silly B3D questions...
| ||
| Just wondered if anyone had any thoughts on these 2 things that have been at the back of my mind for ages - 1. you can set a light to be brighter than 255,255,255, and it does indeed make the scene even brighter, but the docs say the numbers should be 0..255. Why does it work going even brighter? Is it just muliplied up with no side-effects? 2. surfaces - I know more surfaces = less speed, but if I have lots of objects all using the same texture, do they get rendered as a single surface, or will they class as seperate surfaces because they are seperate objects? |
| ||
| its not silly questions... its pretty hard to answer |
| ||
| interesting questions: i have a theory for question 1, as for q2, i have no idea say you have a bitmap with all 255 shades of grey, then you "gamma" you'll notice that the white area's stay white and the adjacent shades will become white when they are hitting the maximum colour rasters. I say this is ONLY a theory so id be interested to know the fact about this. |
| ||
| actually u can go for negative value as well like -255... it will give nice night effect... |
| ||
| surfaces - I know more surfaces = less speed, but if I have lots of objects all using the same texture, do they get rendered as a single surface, or will they class as seperate surfaces because they are seperate objects? Create them from a template mesh using CopyEntity() and they will share; Simply applying the same texture to individual objects does not force sharing where it previously did not exist; It seems possible to apply different textures to entities created from a template without breaking sharing. There was a thread covering this (with some code test I seem to remember) recently... we got a bit arsey with each other (because that's what we do here - heh) but it should still prove useful if you can dig it up. |
| ||
| The last time I checked ( years ago ) a texture applied to several entities would be a single surface, provided they used compatible texture flags. I remember testing this with the castle demo. I added some code to load one of the textures used in the castle. Then I wrote some new data to the texture buffer of my loaded texture. This also changed the appearance of the castle, so it was using the same texture, not a separate copy. |
| ||
| My understanding is that every new object creates a new surface, regardless of whether they share the same texture and flags. In order to do a single surface, they need to be attatched into one object. This code doesn't quite work, since it only uses the texture of cube 1 after using addmesh, but perhaps someone can fill in the blanks for us. This code shows up as a single surface, BUT,... 1. you cannot count surfaces across multiple objects. (does this mean multiple objects=multiple surfaces? I think so) 2. when I merge the two objects into one it shows 1 surface, but the second texture is lost in that example, so it is not a valid test. Can someone make that work? |
| ||
| The last time I checked ( years ago ) a texture applied to several entities would be a single surface, provided they used compatible texture flags. I remember testing this with the castle demo. I added some code to load one of the textures used in the castle. Then I wrote some new data to the texture buffer of my loaded texture. This also changed the appearance of the castle, so it was using the same texture, not a separate copy. I'm not sure that result tells us very much about surface usage... you could create two separate cubes and give them the same texture and this texture would alter on both objects when you wrote to it, but both objects would still have their own surface. Before it got bogged down in miscommunication, I posted some exampler code in this thread that might prove illustrative of how things seem to work. |
| ||
| As far as i am aware every seperate entity ie a child mesh on a .3ds file or a copyentity is a seperate surface, wether they share the same texture or not. Even if the children on the anim mesh share the same texture they are seperate surfaces. |
| ||
| All this speculation has already been answered. Check the code I linked to - a copied entity's surface is equal to that of its template. You get a rendering speed increase just from from taking advantage of this, regardless of textures. |
| ||
| That's still not single surface though. One set of mesh data yes, but creating copied entities still creates multiple surfaces that are rendered seperately. For example, copying a sprite thousands of times will not create a single surface sprite. For meshes you can use AddMesh which will automatically combine surfaces that have matching properties. |
| ||
| so,... are the following statements all true? 1. Every individual texture creates a new surface. 2. Every entity is made of at least one surface 3. Surfaces are not shared among entitys, even when the same texture is used. also, is there a way to do a scene surface count instead of by individual entities? |
| ||
| C1=Createcube():C2=Createcube() Will create two surfaces. You can texture both of these with the same or different textures. As for if any optimisations go on, I think there must be; Way back on a p3 600mhz, I made a racer game by using texture cubes laid out along the shape of the track (My first B3D program i think!) They were all textured the same, and it ran at a full 60-70fps no problem, with 600 peices of track. If I was to load 600 seperate surfaces I did however get around 10fps instead. |
| ||
| Judging by the results in the thread Sledge posted it looks like using COPYENTITY is a much better idea than loading individual copies of the same mesh, or using COPYMESH. I'll have to check how SRX loads stuff like car wheels (of which there can be up to 32 loaded at once) - I'm currently loading a single reference mesh which is then copied for all instances, but I need to check if I'm using COPYENTITY or COPYMESH, if the speed increases can be as much as 50%. |
| ||
| You will be interested to know one of the major speed increases on lower systems with the racer was when I replaced the wheel load code with optimised code that detects if a wheel of the same type was already loaded. If it has, it just "copyentity"s the older wheel. Got an FPS increase of about 25-30fps with this one no a system that used to average out on 40-50fps in the racer. |
| ||
| I use base entities so when a new netity is loaded it checks the bases first and does a copy of that if it exists instead of loading the new mesh. It does give me a big speed increase with a lot of entities. |
| ||
| Cool, I'll have to bear this in mind and update SRX accordingly. |
| ||
| This is causing me a lot of confustion too...seems my Particle system is causing a lot of slowdown in my engine if it goes over 200 particles, despite the fact that I copyentity all the particles from the same base sprite that is loaded at startup. I only do some minor changes, like color and scale, before letting them loose into the game world. So basically every particle is creating it's own surface? Is there a way to make seperate particles share a single surface? Or do they already and my problem is something else? My head hurts... |
| ||
| So basically every particle is creating it's own surface? Yep. A lot of sprites in B3D will slow things down quite fast, even if you've used CopyEntity. Is there a way to make seperate particles share a single surface? Yes, you can create your own sprite system that creates lots of quads in one big mesh. Of course this isn't an easy thing to do (you also have to point all the quads at the camera yourself), but a few people have already created single surface sprite systems which you can use. |
| ||
| Oh man...ouch :-( And my system worked so well and had all the features I wanted... On the other hand, might it become slower to do all the mesh manipulation? I'll try to dig up some single surface sprite systems from the code archives, maybe I'll find something useful. |
| ||
| Orcslayer- 200 particles only? What system spec? It might be the logic code behind them. I could get 700 particles in Supernova before i noticed any lag on my old 1ghz system I assume you're using a custom system and *not* blitz3D CreateSprite() stuff? Personally, I make my sprites using one *triangle* thats larger than the texture i'm putting on it and then center the texture so it fits on the triangle so you can't tell it's just a triangle. This halved the polycount of my system. :) |
| ||
| Cygnus: Doesn't using triangles create overdraw? i.e, the card still has to process alpha'd areas? |
| ||
| All quads use two triangles... i'm just halfing that. if you use triangles it has to process half as many triangles than if you were to use Cubes. |
| ||
| I think quads are generally considered more suitable than tris for particles. I haven't tested it so I can't be sure, but like Tom says quads should render quicker than tris. |
| ||
| How on earth does that work? :P its half as many potential pixel plots! :P either way, my system was quick. Are you saying it would have been quicker to use two tris per sprite rather than just use a UV trick to texture one tri? Just want to know how a quad happens to be quicker :D |
| ||
| I think it's because you have to increase the size of the tri, to compensate for it's shape. |
| ||
| Well, that was something obvious.... that I completely overlooked! However, my textures were pretty simple and just spheres so the triangles didnt have to be any bigger than the ones used in the quads. That also means I was being wasteful with quads. Oh well. Cheers for the enlightenment. |
| ||
| On a side note, I've been messing with blitz internals again recently, I was curious if texture thrashing could be reduced by reordering the entity list based on texture usage, but it works out the same speed wether they're textured randomly or sequentialy. Change the 'ordered' variable to try the other method. |
| ||
| <<So basically every particle is creating it's own surface?>> Yep. A lot of sprites in B3D will slow things down quite fast, even if you've used CopyEntity. That's still not single surface though. One set of mesh data yes, but creating copied entities still creates multiple surfaces that are rendered seperately. How come eveyone who says this completely ignores the fact that the copied entities all have the same surface handle as their template? |
| ||
| I would agree they are single surface via CopyEntity. However, because you can attribute each entity with different properties, i imagine they is some more behind the scenes things happening. Maybe they get broken down to different surfaces when sent to the graphics card. There definetly is a speed difference. |
| ||
| I've just had an idea about loading a lot of different objects into a level - If I have a single object, called BASE - it's loaded as a ANIMMESH and contains 20 child objects, each of which is centred on zero and is one of the objects I want to populate my level with. So, for example, BASE may contain 10 different trees, 2 benches, 4 cars etc... Now, I store this BASE object and every time I want to create a single world object, I use COPYENTITY to duplicate the whole thing, then manually FREE every piece I don't want, leaving just a single child object behind. Imagine that I do this for 100 trees (using the 10 different types within BASE) across a level at startup. Would all the trees now be sharing one surface, despite being seperate entities with different shape meshes? I've written a test program and this does work, but I have no way to quantify whether it's faster or slower than normal, or whether they are all being rendered as the same surface. What we need is a global SURFACES_BEING_RENDERED command, unless anyone can come up with a way of finding out the total number of surfaces in use? |
| ||
| Edit : just tried it, with 10000 objects, loading them seperately gives a framerate of 2.5fps, loading them using the method above gives a framerate of 1.4fps. So loading and placing the objects seperately seems to be better than messing around with COPYENTITY. Very odd. Unless animmeshes do something odd with surfaces? |
| ||
| How come eveyone who says this completely ignores the fact that the copied entities all have the same surface handle as their template? They may have the same surface, but they are not drawn together - they all share the same surface just to save on the memory needed to store tri and vert data. In B3D, everything is rendered on a per-entity basis, so one entity is drawn then another then another, so you have to group surfaces within a single entity. |
| ||
| LoadAnimMesh loads all seperate enities as a new surface. There's your problem :) those 20 child objects may very well be 20 different surfaces! |
| ||
| Ah well, another good idea to file in the bin :) |
| ||
| They may have the same surface, but they are not drawn together - they all share the same surface just to save on the memory needed to store tri and vert data. In B3D, everything is rendered on a per-entity basis, so one entity is drawn then another then another, so you have to group surfaces within a single entity. Thank you. |
   |