My engine discussion thread

This thread is for discussing rendering and other techniques in the context of a structured engine.

Related threads:
Design
Terrain
Actors
Rendering

After trimming down my skeleton, I was able to boost the framerate to acceptable levels. I also implemented an extensive statistics feedback system that helped me to optimize the outer rendering loop. I am very proud of all I have going on here, the mesh density, the view distance, number of actors, and a decent framerate. The next step will be creating super-low-res version of the skeletons and actor meshes, so that a minimum number of bones is used. The FPS is 76 without actors, so there is still a lot of improvement I can make.



Another tip for rendering animations is to still use Blitz's animation system, but only call it once before the outer rendering loop, then hide the animated mesh after you update and render it. Only update animation for meshes that are not hidden or far away:

Function AnimateFrame(entity,sequence,frame#,percent=False)
Animate entity,3,1,sequence,0
length=AnimLength(entity)
If percent
	frame=frame*length
	Else
	frame=frame/length
	EndIf
Animate entity,1,frame,sequence
End Function

So you animation routine would look like this:

For each model
If Visible(model)
	ShowEntity model
	Next
UpdateWorld
Renderworld
For each model
	HideEntity model
	Next

I actually render each model in a separate pass. This lets you set up a unique lighting environment for each model, based on visibility between the model and light sources. Just do an EntityVisible() to see of the model is in the light or the shadow.

In some engines ive noticed lets say the render distance is 300 (some measurement). But for smaller, and less important objects the render distance is 200 or 150.

This would help if you rendering a variety of objects in a big space.

But from the screen above, your engine wouldnt really require anything like that?

That's not a bad idea. I figure, if performance is good now, let's push it further and really take it to the limit. My trees start looking like crap from a mile away anyways, so I might as well hide them and just leave a terrain silhouette in the fog.

or for tree's that are far a away you could build a mesh and paint a forrest texture on it, that way you see the green of the trees so they dont just 'pop up'. and you vastly reduce your polygon count. in adition something like this wouldnt be too hard to code.

For FPS games such as a WW2 i hear you might be using the engine for, i think the drawing distance is crucial importance. Maybe if you played Operation Flashpoint you know. And if you 'zoom in' with binoculars and stuff you have to solve that too, how trees convert from low to high poly count if you zoom into them from distance. It takes a bit of effort to make it real good.

Also :P place some rocks, logs, branches and dirt patches on that ground!

This is very important also in relation to this:



In Battlefield 1942 (at least, in older versions) the developers forgot to animate characters in the distance when viewed through a sniper scope, so they sort of slide around instead of walking...

Yeah but when you zoom, your field of view is narrowed, so you can lose a lot of polys even though you are gaining them.

I can make much prettier terrain, but the point here is to test for max size and view range.

71k tris for terrain and trees only is not well balanced imho. And 17ms is not 31 FPS, but 60.

I think the viewrange is not high engough for an outdoor scenery. It looks like a "due to crappy hardware we have very bad weather these days".

True Sniper rifles are made for 1 mile...

I increased the view range and terrain size with no speed hit. The low FPS is caused by rendering 30 actors. I am working to reduce the number of bones in the far-away versions. The framerate is 70+ without actors.

I am not sure what you mean by "well balanced".

71K tris seems good though.

"71K tris seems good though. "

would depend on the system thats drawing the 70k tris. But thats not a bad speed at all really, allthough not a high surface count judging by the screenshot.

also currently its just rendering and doesn't have any gameplay as far as I can see. looks nice though :)

I liked the video with tree shadows etc that was published a coupl eof weeks ago. that was pretty sweet. Really nice to see people trying to push blitz past what were used to seeing and making a really good go at a game.

I first didn't see that the 30 chars are part of the 70k, so it seems to be ok. Only one thing halo, something design-related: the trees are looking like baby-trees of 1.4 meter height, due to their special shape. older/higher trees have diffrent shapes. This way the scene is unneccessarily looking smaller than it is, also the chars are looking very small this way. The trunk of higher (fir)trees are naked at the lower part and they have less dense limbs/leaves. Just my 2c.

Hi Halo

I was following your thread on large numbers of actors and since I'm also interested in having large numbers of actors on screen I decided to do some experiments on minimising the impact on the animation chokepoint.

Reducing the bones certainly reduces the overhead, but another way is to reduce the length of animation and the number of frames. I started with 800 low poly boned figures but with no animation, and sequentially added, through LoadAnimSeq, more animations and the degradation was noticeable, especially when five animations were added to each figure. The best I was able to get was 30 FPS with 480 figures with 30 frames of animation each (not quite Rome Total War territory). For distant figures you could just Copyentity an Idle figure to replace a Walking figure but you would lose any smooth transition from one animation to another.

Back to the lab.

Cheers

GrumpyOldMan

You can use copyentity anyways, and the animation state will be kept separate.

It seems updating the animation only takes 0-1 msecs. Rendering characters is by far the most intensive process I am dealing with, usually taking a good 10 msecs for 30 actors.

Another issue to consider, which is impossible to analyze, is the bone update time, which I presume is handled in the RenderWorld() routine.

Hi Halo

With rendering the actors have you tried Addmesh'ing to see if cutting the number of surfaces down (bearing in mind the limit on tris within one surface) gives you any speed increase? I've tried it and it was minimal but I'm only using 250-250 tri figures.

Cheers

GrumpyOldMan

Forgive me if this is a stupid idea - but what about replacing meshes with animated sprites at a distance that varies depending on the density of animated figures close to the camera?