More info on multi-pass rendering

It seems that the RenderWorld() command involves significant overhead beyond the poly count when used in windowed mode, but not in fullscreen. This explains why it made my editor choke, even after prelimnary tests to see if the technique was even feasible (must have been in fullscreen).

This means you can keep your staticmeshes as instances of a single reference, that you position, rotate, and scale. It also means you can set the lighting environment up on-the-fly for each static mesh! If a light and a mesh are nto visible to each other, don't use the light. Use the mesh/light distance and light color to fake a light range, instead of dealing with crappy infinite lights.

Hardware lighting is MUCH faster than manually coloring the vertices, and you can use specular higlights. This is great!

Sounds good, not sure about the issues with Windowed mode but will try and look into it.

Thanks, Simon!

There are two unique meshes in this scene, plus the terrain meshes. The same renders in windowed mode give 5-10 fps.





Testing indicates that rendering instances is much faster than rendering unique meshes, probably because you don't have to pass huge amount of data to the gfx card.

I don't know how this compares to merged meshes, but there is one variable that will work to increase the speed of referenced meshes. When meshes are merged, if any part of the mesh is drawn, the entire mesh is drawn. With referenced meshes, offscreen instances are culled. Plus, they are a hell of a lot easier to light and work with. Not to mention the option of LOD.

Plus you can use alpha-masked grass and not worry about your z-order getting screwed up, because you don't have to merge meshes for speed.

This is actually a vital feature of any engine imo.

In hardware you can do it properly.

Say you have Entity1, with 8 surfaces. A tree.

CopyEntity(tree) 100x obviously = 800 surfaces+Overheads mentioned above.

In blitz, (afaik!) this all happens surface by surface. Result =Very slow framerate
on average pcs.

But, with a simple bit of code, you can order surfaces in order of ownership.
Now for surface 1, you lock it's vertex/color/normal streams.
then you can render it all in one go, the only changes per surface=entity
specific states (color/alpha, minimal overheads)

And the results are a engine that performs over 50% faster in any real world situration.

struct batch{ 
	surface *surf;
	entity *ent;
	batch *next;
	batch *last; 
};

BBD void BBC batchAddSurface(batch *bat,surface *surf,entity*ent,bool addToEnd){
batch *id=new batch;
bool found=false;
bool done=false;
	id->surf=surf;
	id->ent=ent;
	if(addToEnd==true){
		bat->last->next=id;
		id->last=bat->last;
		id->next=bat;
		bat->last=id;
		return;
	};
	batch *check=bat->next;
	while(done==false){
		if(check->surf=surf){
			found=true;
		}else{
			if(found==true){
				id->next=check;
				id->last=check->last;
				check->last->next=id;
				check->last=id;
				found=false;
				done=true;
			};
		};
		check=check->next;
		if(check==bat){
			if(found==true || done==false){
				id->next=check;
				id->last=check->last;
				check->last->next=id;
				check->last=id;
				found=false;
				done=true;
				done=true;
			};
		};
	};
};

With that bit of code, mark could automatically create a sorted 'list' of surfaces,
while still retaining unique entity props...it's practically impossible however
to emulate it in b3d it's self(at least I couldn't.)

I finally figured it out.

In full-screen mode, antialias with multiple passes is fast. When you are windowed mode, AND you are using multiple passes, AND antialiasing is on, it will be really slow, like 5 fps.

So all I have to do is turn off antialiasing in the editor. :P