Horde3D

We have taken the performance concerns that were expressed in a few threads seriously and worked on some optimizations.

Although there is still room for improvements in the future, the speed gains so far are quite satisfying: In Beta2 CodeAnalyst showed a CPU workload of 3.7% for Horde3D.dll when running the Chicago sample. With the upcoming Beta3, it is only 2.2% when the characters have no LOD. The new LOD system costs some CPU performance (resulting in aprox. 2.9% workload) but brings very much on the GPU side and increases the framerate a lot.

Hi dear marciano, thanks a lot for your effort on improving engine. I have a little question, when would you plan to add SIMD features to engine ? I've an idea about how to solve the problems with vectorized math lib. I think it's better to use unaligned memory instead of aligned memory [m128 union], memory access is a little slower in unaligned mode, but this avoids many problems like changing engine structure and ...

Best Regards,
Siavash.

Are there any really significant changes to rendering and shaders in the works/planning? I've been working on some stuff in there, hence my heavy silence lately. Teaser keyword: G80

Geometry shaders?

_________________
Tristam MacDonald - [swiftcoding]

Cool that you are working on that. There are some vague plans to create a graphics API abstraction layer for the renderer so that it can easily be ported to d3d (an other APIs, e.g. GL ES) but it is not yet clear when this will be realized (time is the limiting factor ).

I can confirm the performance improvements in the Chicago sample. The Knight sample, however, runs significantly slower compared to Beta 2. I checked out the current head revision in the SF SVN. My system is a Core 2 3GHZ and a GF8800GT with the latest official drivers, Vista x64. Can anyone confirm this?

Same here.

In the knight sample I'm getting around 365FPS with the svn version instead of 430FPS with the Beta 2.0 version.

Thanks for pointing this out. CodeAnalyst shows that the CPU time for the knight sample is also clearly lower (0.99% against 1.22%). The reason why the Knight sample runs slower is that a small hacky optimization got unconsciously removed: the shadowmap context in the old parallax shader was commented out, so there were no shadow computations for the sphere the knight is standing on. In the new model übershader this no longer the case and that's why it appears slower.

Hi, I am back from the dead

Is this still on the works? I think gfx API abstraction would really be a big step forward into making Horde3D gfx API agnostic, and more extensible. Personally i don't have enough experience with d3d to design a good cross graphics API abstraction layer but i will be interested in the development process, and contribute with OGL ES backend needs.

I dropped all my horde3d porting efforts (hence i have been missing from the forums) and started using PowerVR sample SDK engine since my focus is on the OpenPandora and BeagleBoard powerVR powered devices. The sample SDK engine has many framework utilities built-in (many utility functions are provided and well documented; I really did not want to code them myself). However I would like to contribute to a less vendor oriented project, and one that would allow me to build for desktop and mobile devices using the same source code. Using the same source code it should be possible to have at least 3 diff build targets: OpenGL (Debug/Release), D3D9(Debug/Release), OGLES2.x(Debug/Release), ...

Congrats on Beta 3! It has many cool improvements that i was too lazy (or did not know how-to) to implement myself.
So i guess my question is: What features are being worked on next, and what milestone do you guys have pointed for the graphics API abstraction layer?

Welcome back

Nicolas and I talked a bit about the abstraction layer. We haven't started anything yet, but Nicolas proposed some kind of render state orientated rendering API, like it's done in DX10/11. Concerning an ES port I wanted to start by trying to port things to Windows Mobile by exluding everything shader based and only run the debug rendering. If the performance is not that bad, I guess the port to ES 2.0 shouldn't be such a great problem. I already downloaded the ATI ES 2.0 emulator and ported the knight sample application code to the EGL based context creation. But I won't start porting rendering code unless the rendering abstraction layer is defined. I would be happy if we get something working until june, when the Toshiba TG01 comes out.

Thanks

I am only familiar with a few abstraction layers. The one on Eberly's Wild Magic 4.x engine that is documented in the 3D Game Engine Design 2nd edition book and the OGRE3D approach. I have also read some slides by Dan Gisburg from ATI on Sushi Demo Engine that supports DX9/10, OGL, OGL ES 2.x that points out the main challenges but does not provide code or straight to implementation solutions... I have never done any implementation or design work on such an abstraction layer. Just taking a macrovision of the issue i can see that there will be the need to refactor many lines and abstract certain parts of the engine to supply certain facilities that are needed (shader compilation and stitching, etc...)

Regarding the software/hardware stack. The only ES 2.x HW accelerated device that is widely available right now is the BeagleBoard with the latest device drivers from TI for Linux. I have build and run a few demos using powerVR SDK engine that work well. It would be good if we could abstract the utPlatform to a level high enough to encapsulate GLFW, and PVRShell instead of having to support each mobile platform individually (basically duplicating what PVRShell already does). The main reasons why i moved to PowerVR SDK is PVRShell and PVRTools (i hate writing platform specific code. "plumbing code").

It would be cool to have an idea of what the abstraction layer is going to look like, i would really like to learn how to build a good gfx abstraction layer.

I'm right back from GDC and did not yet have much time to think about that. As you state there is not much info about API abstraction layers so some research will be required. I guess it will take a few iterations until our abstraction layer can be considered as "good"

Hope you had fun and picked up a few new tricks

I agree. But i hope you guys can share a bit more in regards of the direction you are thinking on going, what papers are you reading and stuff like that so we are all on the same page. Cuz beta3 changes hit most people by surprise i would think. Even if it's small tweets or something just to keep the community on the loop regarding major decisions.

All the important changes for Beta3 were announced and put to discussion in the Development Section a long time before Beta3 had been released. I would guess the problem is rather that you have not been around for some time
Honestly, I don't know any other resources for the abstraction layer other than the ones you mentioned. I really did not yet have much time to spend on the topic. The only thing that is quite probable is that the interface will be D3D10-like (using state objects).

Well that is true, but i did not find any info regarding the new material system... perhaps the topic of the thread does not point it out and that is why i missed it.

I found the support for DDS thread, very nice to see it added and the way you guys shared the discussion

BTW, i was not even thinking about having detailed discussions, more along the lines of you guys twit or something like that. Like: "Thinking about adding xyz feature. Found uvw paper, looks like a good solution."



That's cool, i was asking because i really would like to know more about supporting different platforms in the same code branch, and not have branches and patchs for each subsystem. Using the D3D10 model looks like a solid bet. It is notoriously popular in the gaming community. Most studios are using d3d according to recent surveys. I don't know d3d that well, so it's going to be a fun learning experience