Horde3D

Hi attila,

first congratulations on shipping Offroad Legends. I didn't have a chance yet to try it out but it looks great from the videos you posted!

Regarding the remaining OpenGL states in egRenderer.cpp: I'm very busy with work but this shouldn't take too much time, so I can try to take care of it.

The idea is that the states get grouped as in D3D11 (rasterizer, blend, depth/stencil) and encoded in bitfields so that you can easily get a hash with which you can retrieve a d3d state object from a cache in the d3d device wrapper. That way Horde will still remain flexible in terms of render state management (for example shader FX states overwritten by engine code) and the performance impact for the d3d backend would be acceptable.

When do you plan to work on the D3D11 backend so that you would need to have the update?

That sounds great.



I have already started working on to support the Metro platform, but currently doing it in my spare time. It is not high priority as our target platforms (Windows Phone 8 and Windows RT) are not yet released. Porting other parts of the engine could take 2-3 months probably. So it would be great if after that I could work on horde3d's D3D11 backend.
But I know that you are busy at work and doing this in your spare time.
Thanks again for this great engine!

Hi, Volker, thanks for your GLES port,
I've compiled and ran successfully on my iPad2 and the new iPad.
But I find it's so weird that the frame rates of Knight is around 30fps on iPad2 and 20~30fps on new iPad, but it's extremely slow only 5~7fps on new iPad and 7~10fps on iPad2 even when render only one model doesn't change anything.
I can not find why, can you give some suggestions ?

antmanler: maybe your ipad3 was in retina resolution. (2048x1536)
ah, i see your problem is not the difference between ipad2 and 3, but the one-model framerate.
did you check your log? if the app logging in every frame, its influences the frame rate.

I compiled from SDK 5.0 and GLKView default size is 1024x768

It work out when I commented out adding platform scene:

then the framerate return to normal, about 30fps on ipad3 (in 1024x768) with 100 Smith.

This may result from the geometry file of platform scene, but I still could not find what's wrong.

Just found this on the Real-Time Rendering Blog:



This has nothing to do with the previous posts, but I guess this is the right place to share it

I have started to work on the d3d11 port. Did you have any free time to work on this Marciano ?


A little offtopic:
I have also started to do some optimization on h3dRender. Culling was fairly inefficient as we have 3 drawgeometries (opaque,alphatest,alphablend) in our pipeline and h3dRender currently does the culling for each drawgeom with the same parameters. So I split updatequeues into two function: cull and filter_sort and does the culling only once. It made the culling nearly three times faster.

The distant goal could be something like in this presentation: http://bitsquid.se/presentations/flexib ... tforms.pdf.

h3dRender could have 4 stages:
1. culling visible objects (camera, light and shadow frustums) - probably more cache friendly to cull an object for each frustum at once
2. draw objects into an intermediate command stream
3. sort command stream
4. issue commands to device

stage 1 and 2 could be split into jobs
stage 3 could use some parallel_sort if needed
stage 4 could be parallel on d3d11, use main thread on OpenGL

what do you think about this design?

Hi attila, the render state refactoring was submitted today. All OpenGL calls are encapsulated by the RDI now, so there are no direct gl calls in the Renderer class any more. While this works well in the samples, it definitely needs to be tested in a more complex application though to make sure that no new bugs were introduced. As states are organized similarly to D3D10/11 state blocks, this should make your port a lot easier.

Yeah, optimizing the culling was on the TODO list for a long time. I was thinking of gathering all views into the scene (camera and shadow frustums) in a first pass and then cull scene objects against the list of views, generating a bit mask which describes for each object in which views it is visible. Objects which have a non-zero view mask would go into an update stage where resources for rendering are prepared (updating buffers etc.) and render items are generated. Those get sorted into batches and finally dispatched to the graphics API. This is all quite similar to what you describe and could definitely be parallelized using a job system without too much hassle.

Wow. Thanks a lot! This will make a d3d port much easier. I will merge the trunk with my branch and tell if i find any problem.
I will work on a d3d11 port and share the code when i'm finished. Hopefully everything will go smoothly. My only remaning concern is about constant buffers.



Great to hear that you were also thinking about something similar. I will post the code when I'm finished, maybe you will find it useful.
I'm also trying to optimize drawrenderables but still without any success. I've tried to optimize the string compares (context, uniform, texture lookup).
I've replaced strings with an id (int) but it didn't give a significant speedup. Maybe I have too small number of materials in my test framework.

I finished the merging. It seems to work fine, the only problem I had that I don't preserve OGL states between GUI/H3D rendering.

I added the code below to force renderstates sets on the first commitStates().



some other thing I found while merging(not related to OGL states).
In RenderDevice::createTexture()
instead of tex.memSize = calcTextureSize( format, width, height, depth );
I'm using tex.memSize = calcTextureSize( format, width, height, tex.depth );
because tex.depth is set 1 when type is not texture3d. (depth param is 0 when loaded with loadSTBI)

In RenderDevice.h I think there is no need for virtual destructor and init. (was probably needed when Renderer was a subclass of RendererBase)

Thanks again for this changes.

I had a strange slowdown with the new version. Framerate was nearly halved.
I'm using PowerVR es2 emulator on a windows7 pc.
It seems the problem is with this lines:

if( !_newBlendState.alphaToCoverageEnable ) glDisable( GL_SAMPLE_ALPHA_TO_COVERAGE );
else glEnable( GL_SAMPLE_ALPHA_TO_COVERAGE );

the alphaToCoverageEnable was disabled, but it seems that even the glDisable caused the framerate drop.
This is probably an emulator/driver bug.

After commenting out these lines the new version is 6-7% faster than the previous h3d version. (state caching seems to work well)

Thanks for your feedback, good to see that the changes are an overall win then! The small issues you mentioned should be fixed now.

For mobiles it might even be worth trying if setting each sub-state within the blocks only when it really changes gives and advantage, although that certainly depends on the driver and how it handles redundant state changes.

Thanks for the quick update.

One small thing I found about the state array trick:


Currently the arrays are filled at each call (tested on msvc9 relase build). Adding a static and maybe const keywords eliminated this.

Dear OpenGL ES developers.

I found two es2 implementations in the community branch(ES_Test, Horde3D_IOS), I would like to ask permission to use them in horde3d-x github repo GLES2 branch. I would like to merge them with my es2 implementation.

Probably the licensing allows this, but I don't want to "steal" anybody's work.

Thanks

Go ahead regarding the IOS code. I would be happy if it would be merged into a unified ES 2.0 branch. Not sure about who had contributed to the ES_Test branch. I'm currently on a tablet where svn browsing is no fun. But I guess there should be no problem, as far as I made contributions (can't remember) there is no limitation from my side.