Fentinor build

[Canardia]

CEGUI is still taking way too much FPS, it should be always 0. And in the log I don't see how long the game code took.

[VeTaL]

<> - Updating Framework: 6

UpdateFramework();

 

 

<> - Updating World: 0

_stateReturns = _activeState->UpdateState(_deltaTime);

__raise updateEvent->UpdateEvent( _deltaTime );

 

 

<> - Rendering Framework: 17

RenderFramework();

 

 

<> - Rendering World: 0

_activeState->RenderState(_deltaTime);

__raise renderEvent->RenderEvent( _deltaTime );

 

 

<> - Rendering Cegui: 4

_activeState->RenderGuiState(_deltaTime);

__raise guiRenderEvent->RenderGuiEvent( _deltaTime ); // cegui

 

Do Cegui render takes 0 in your test?

[Canardia]

You don't have any game code still, and what is Render World doing? Isn't Framework already rendering all 3 worlds?

[VeTaL]

my code:

 

1) _stateReturns = _activeState->UpdateState(_deltaTime);

this is

int StateGame::UpdateState( float _deltaTime )
{
SingletonOisManager.Update();                     // ois input
SingletonLevelManager.Update(_deltaTime); // this contains UpdateFramework();, now it is empty

return GameState;
}

2) __raise updateEvent->UpdateEvent( _deltaTime );

camera and player updates are subscribed there

 

3) _activeState->RenderState(_deltaTime);

is doing nothing. Previously, RenderFramework(); was there, but now its also empty

 

4) __raise renderEvent->RenderEvent( _deltaTime );

this called imgui debug panels (player and camera had their own debug panels), also disabled for now

 

 

Also, i'm planning to change "__raise" to http://www.codeproject.com/KB/cpp/FastDelegate.aspx

[VeTaL]

Made simple tests for Cegui. Hope, they would be usefull for someone.

 

1) New application, created with LEBuilder (rotating cube, C++): 280-282 FPS

		TurnEntity( mesh, Vec3( AppSpeed()*0.5f ) );     

		UpdateFramework();                
		RenderFramework();                

		Flip( 0 );        

 

2) Rotating cube + simple Cegui render (taken here): 262-265 FPS

	TurnEntity( mesh, Vec3( AppSpeed()*0.5f ) );   

	UpdateFramework();
	RenderFramework();

	glPixelStoref(0x806E, 0); 
	glPixelStoref(GL_PACK_ROW_LENGTH, 0); 
	glPixelStoref(GL_UNPACK_ROW_LENGTH, 0); 

	CEGUI::System::getSingleton().renderGUI();

	Flip(0);

 

3) Rotating cube + simple Cegui render + cegui cursor: 265 FPS

if( xMouse != MouseX() || yMouse != MouseY() ){
		CEGUI::System::getSingleton().injectMousePosition( (float)MouseX(), (float)MouseY() );
		yMouse = MouseY();
		xMouse = MouseX();
	}

	TurnEntity( mesh, Vec3( AppSpeed()*0.5f ) );   

	UpdateFramework();
	RenderFramework();

	glPixelStoref(0x806E, 0); 
	glPixelStoref(GL_PACK_ROW_LENGTH, 0); 
	glPixelStoref(GL_UNPACK_ROW_LENGTH, 0); 

	CEGUI::System::getSingleton().renderGUI();

	Flip(0);

[Canardia]

I'm writing a small and fast GUI right now for LEFlow. So far hovering and clicking of buttons work, also z-order of GUI elements, and it takes 0 FPS.

What GUI features do you need for your game?

[VeTaL]

Hm... Yep, there are some guis, but i dont want to invent new own gui right now

Maybe, later i'll convert Imgui to pure OpenGl (instead of SDL, like now), but it is needed to make Layout Editor and so on... maybe later

 

But yes, Cegui eats too much (comparing with 0)

[Canardia]

You don't need to invent a new GUI, because I am already doing it Just tell me what features you need.

[VeTaL]

Imgui and wishes are sent to you

[Josh]

Turn full statistics on in the editor and post screenshots.

 

I can't look at your models because they're all in a password-protected pak file.

[VeTaL]

For those, who are trying to help i already sent a PM with password.

 

Well, for now, i think, i can open password.

[YouGroove]

Do you use LOD on your level ? perhaps it could save some frames also

And for lights, why not deactivating some non important/significant lights and their shadows when you are far away from them ?

If you disable all shadows , is the result better or not in terms of Fps caus it depends , but eat a lot also !

 

I'm interested in all optimisations you'll do it could serve me and perhaps others for our projects.

So don't hesitate to post you results and solutions

[VeTaL]

//Do you use LOD on your level ?

Of course

 

//And for lights, why not deactivating some non important/significant lights and their shadows when you are far away from them

the scene is too small for that, i think

 

//So don't hesitate to post you results and solutions

Of course, thats why i ask for tutorials and solutions section here

 

What about current models, here they are: http://www.speedyshare.com/files/29762947/Fentinor.7z

password: nOde46repLY30zOA47yak!

 

Head of this topic is updated.

[macklebee]

From what I see the thing that drops the fps the greatest is the flickering light script. If I replace those objects with just a simple pointlight, the fps is basically a flat 60 fps (vsynch on obviously) in a standalone lua script. With the flickering lights, the fps will drop down to 15 whenever those lights are viewed. You could try what Josh did in the firepit script and fake the range of the light by changing the color of the light instead of actually changing the light range every update.

 

btw, I love the artwork... fantastic stuff! reminds me of torchlight.

[YouGroove]

Why not doing like commercial games ?

Use lightmaps, and activate lights only when character is near, i think you could save lot of Fps this way !

[Josh]

Okay, first of all the scene looks great. I love how you blended the cliffs with the terrain, and the coloring and use of coronas is great.

 

Your flickering light script was the main culprit. Replace the Update() function with this:

	function object:Draw()
	local r = self.random and self.random or 0
	--if math.random(1,1.5) == 1 then r = object.light:GetRange()-r else r = object.light:GetRange()+r end

	--object.light:SetColor(r)

	--if self.maxrange~=nil then
	--	if object.light:GetRange() > self.maxrange then object.light:SetRange(self.maxrange) end
	--end

	--if self.minrange~=nil then
	--	if object.light:GetRange() < self.minrange then object.light:SetRange(self.minrange) end
	--end
end

 

The second thing that jumps out at me is the high entity draw count. It's drawing almost 4000 entities each frame, which is more than our Zone stress test.

 

Some of your models have a lot of redundant surfaces. This model, for example, has six surfaces and it only needs one. That means if you would otherwise be drawing 200 instances for this object (just an arbitrary number) with the extra surfaces, you are now drawing 1200 instances, and six times as many reference surfaces! Fortunately, we have a little tool to make this easier, but be careful because this will collapse all models:

http://www.leadwerks.com/werkspace/files/file/140-gmf-processor

 

Finally, building scenes out of lots of individual parts is less efficient than loading bigger chunks of scenery. I understand that it is easier to work with, and you might be able to get away with it if you collapse your models like in the previous point I made, but just keep in mind more entities overall = slower:

 

BTW, that time of day script is looking fantastic. It's come a long ways since the videos I first saw.

[Josh]

I just noticed you are using occlusion on a lot of objects. The occlusion test itself has a cost, so you only want to use it when the savings will be significant...by default, only animated meshes and lights use occlusion testing. You should disable this on little things like this, because each tested object requires a single-pass draw call.

 

 

During development of the Zone scene, we already dealt with all the bottlenecks you are experiencing. If you follow my tips, you will be able to get optimum performance for this fantastic scene.

[YouGroove]

Great tips !

I htink it's a general purpose that drawing lot of entities has a big cost instead of drawing "glued" entities or a lot as a single mesh.

For a level made in UT3, there was a trick for the stones on the floor :There was some 6*6 stones , and you thaught they weere individual entities, but it was one entitie only , yyou could rotate it 90° or 180° to creatre some variation. And the scene had some individual stones entities to bring bigger variations but theywas not a lot !

 

For occlusion, we can do a rectangle distance occlusion or LOD in some sort , it could be fast and work in lot of situations no ?

[VeTaL]

Wow, thats it

 

Thanks a lot, Josh. Of course, i'll try with your advices

 

//For occlusion, we can do a rectangle distance occlusion or LOD in some sort , it could be fast and work in lot of situations no ?

For now i'm paying with distance culling - the only culling thing avaivable

[L B]

Your scene is fantastic mate. I can't really help any more than Josh or Mika or anyone else on the speed concerns, but my jaw did drop.

 

And I missed this thread for so long - this is why we need to have a gallery banner!