Horde3D

Just found this: http://www.mediafire.com/view/?7k0q4guxgm74y2g . The guy is already working on this in a GSOC project.
It seems like ogre3d has similar issues than h3d, like the scene culling is done multiple times for each type of geometry (opaque/transparent).

I'm just wondering how can we gather people to work on projects like this.

May be hiring an individual programmer through crowd funding? Example : KHR_Debug Code For Mesa. However that requires advertising and big coverage in popular sources.

My favorite slide is #19 . Joking aside, I think that requires a near complete rewrite of engine from scratch. Only Horde3D logo will stay untouched.

It is always tempting to start from scratch, bit it is a huge work. I think what horde3d ( and every opensource project ) needs is steady updates. I wouldn't consider using an engine that was last updated more than 2 years ago ( no offense ). I'm working on the es2 and d3d11 ports mainly in my spare time, and even that is much more work than I thought. I'm also planning to give an example on how to use h3d with cocos2d-x https://github.com/cocos2d/cocos2d-x which has much more follower and more active community than h3d has.
They also have roadmaps with clear goals/issues: http://cocos2d-x.org/projects/cocos2d-x/roadmap.


But finding a talented 3d engine programmer who knows horde3d well and doesn't work for a big company would not be too easy.

These days I only recommend Horde3D for people to use if its current level of features are enough for them and they aren't going to expect any new features or updates. Otherwise, gameplay3D is a very nice alternative to all open source engines out there.

attila your hard work on OpenGL ES and DirectX ports is very appreciable, but I'm personally done with Horde3D. There is no point in using or working on any project when project maintainer doesn't want it to be anything more than a hobby project.

I might be able to help with this. I'm using Horde3D for my current engine and I don't really want to switch since most other 3d engines are terribly bloated.

Sorry to hear that. For me/us it is much more than a hobby, we earn money with this engine. So we would like to support/advance it to be able to use it for a long time. In its current state it is good enough for us now. But without "modernization" there will be a huge gap in quality between our games and concurrent games using closed source engines like Unity,UDK, ProjectAnarchy.


That would be great. I also like h3d because it is small but very flexible.
We could discuss here what changes should be done. What changes would you like to do/see in h3d?

My list:
- Getting rid of the scene graph http://horde3d.org/forums/viewtopic.php?f=8&t=1117
- Model Resources http://horde3d.org/forums/viewtopic.php?f=8&t=733
- Shader System: Context State Combination http://horde3d.org/forums/viewtopic.php?f=8&t=1873
- directional light shadowmap
- crossplatfrom (hlsl/glsl) shader definition ( something like: Shaders authored in our in-house meta-language, Shader snippets in HLSL/Cg & GLSL, Über-shader approach, pre-processor branching and snippet combining, Shader permutations needed dictated by project material files )
- uniform/constant buffer support (buffer for current "system" parameters, and materials could define a buffer)
- parellelization of the engine ( culling, animation blending, rendering: http://www.bitsquid.se/presentations/flexible-rendering-multiple-platforms.pdf )
- Geometry/Hull/Domain/compute shader support
- pipeline command extension (like the current nodetype/renderfunc extensions; custom code could be added to the pipeline
like tonemapping with compute shader or a different deferred light loop implementation)

updated:
- Better particle engine with a crossplatform editor ( we are using pyro http://pyro.fenomen-games.com/now, but it is not as efficient/flexible as we would like )

I`m making a pc only game engine, using Horde3D, Havok Physics and Havok Animation.

Scene graph is also useless for me, physics will caculate the world transform, and animation skinning is just
data, havok animation tell me the matrix, and I put it to the matrix plate.

Horde3d is very small and clean, the codebase is easy to understand, I add my custom geometry and material resource for loading data from havok pipeline.

I was thinking about doing a "rewrite" for quite some time, too. When decomposing a game engine into libraries, I think of:

• Entity Component System: The glue driving the simulation (aka. pure logic). Done (not open source, yet).
• 3D Graphics: The notion of a visual (vertices, materials, transformation), culled and rendered (sorted by material, etc.). There is nothing open sourced for this (not even talking about platform support).
• 3D Audio: The notion of an audible (samples, transformation, velocity), mixed and rendered (one listener). FMOD, OpenAL, PortAudio, ... nothing to do here.
• Physics: Bullet and Box2D do an excellent job... nothing to do here.
• Networking: Distributed, authoritative state synchronization ... nothing to do here, at least for me (internal library, sorry).
• Resources: dxt/png/webp, mp3/opus and mp4/webm are fine... 3D models can be a real pain as tooling is mediocre. OpenCTM might be worth a try.
• Platform: SDL 2.0, Qt 5 or platform specific solutions (depending on requirements). Nothing to do here.

Why am I listing this? I think its a good idea to limit the scope of "3D Graphics". IMHO: scene graph, file formats and tooling are totally out of scope. An "API" for debugging/instrumenting the renderer is not - think of V8 remote debugging. This would facilitate cross-platform development and in-game WYSIWYG, if done right - live updating meshes and shaders without relaunching the application, etc.

Regards,
Christoph

I also really like this 3D rendering engine due to its simplicity: it claims to do one thing and it seems to do it well. Open sourced.

IMHO, I also think there are parts completely out of the scope which should be removed or moved to the Utility lib (scene graph is one of these), as attila already pointed out.

BTW, the big problem is: we can all work on the attila's Git clone repo (thank you!), but what about the future? If there are no chances to see these changes and efforts on the official repo in short time and a new life (& modernization) to the website/wiki, why spend time and efforts on this (quite dead, due to an unclear leadership management) project?

Maybe we can consider the idea to push our efforts to a new-brand open source 3D RENDERING engine based on Horde3D, more community-based (if the Eclipse license allows us to do it)

I've found this: https://github.com/bkaradzic/bgfx. It is much lower level than h3d, but extremely well designed and futureproof.
It is actively developed, I've chatted with the developer he said "it's going to be supported and developed in foreseeable future."
I'm thinking about creating something like h3d on top of it (but with changes like adding model resources, replacing scene graph with a simpler spatial graph ).
I don't really know EPL so I don't know if we should start from scratch or can use certain parts of h3d, but I think that apart from the API/file formats and the goals like
"keep it simple but flexible" they will be very different in the inside.
If anyone would like to join feel free to pm me, as it would be non compatible with h3d, we should discuss it elsewhere.

Sorry if I did sound blaming you attila, by project maintainer, I meant marciano. May be project leader was the right word. Like Zuck mentioned, it's pointless if these improvements never get official.

Like others mentioned, Scene Graph should be an optional part of graphics engine and moved to the utilities library. However I have a bad feeling about bgfx and other similar libraries wrapping both Direct3D and OpenGL APIs and trying to be an all-in-one engine. In my humble opinion it just makes the engine over complicated and harder to maintain, same route Ogre3D, Irrlicht and others took.

It isn't 2002 anymore, and display drivers provide good OpenGL support with same quality and performance as Direct3D. Both APIs are providing same functionality and features. So, adding Direct3D to the mix is just asking for trouble. A graphics engine supporting OpenGL2, 3 and 4 feature wise is higher than enough and easier to maintain.

Anyway I think a successful engine should be more efficient on targeted platform. Words Simple, Flexible and Next-Gen are just overrated. A slow, very easy to use, customizable to hell with low memory footprint is just a bad joke.


Also you forgot to enable PM button from User Control Panel.

I thought that you were thinking about marciano/Volker. I didn't blame them, they(and others) made this great engine, without it we(dogbytegames) couldn't accomplish what we did. It's bad that now they have no time for further development, but we got it for free with sourcecode. we can modify/upgrade. I have learned a lot from working with this engine.


It would be great that if OpenGL would be available on every platform. But MS keeps using d3d, on WinPhone8/WinRT/Xbox only d3d is available. You can wrap D3D to have GL like interface but I think it is better to add a higher level interface on top of lowlevel APIs.


Thanks. It is hopefully enabled now.

I think support for gaming consoles is out of league for an open source engine and we shouldn't worry about it. For example, on PlayStation and it's variants people usually tend to use their native API, not OpenGL. Also for developing on XBOX you will need to be a registered developer to use C++, which costs pockets full of money, and individual developers should go with C# and XNA. See this: Business and Law

I think you guys should focus on PC and Android mobile phones. Also, in my opinion it is better to keep the engine (internally) splited to a PC optimized version and a mobile optimized version, because they totally differ in hardware capabilities and limitations.

Thanks for pointing this out - its pretty much what I had in mind. Did you already try and profile it (does it contain bugs, fail cache coherence, has pipeline stalls, etc)?

As for Horde3D: I dislike the idea of breaking with Horde3D as a project. I believe that thinning the web page and moving things to GitHub will solve problems: It'll simplify things due to pull requests and the "master branch" effect - bye, bye death march style release cycles and unattended MediaWikis. The maintenance work by Volker and others should decrease quite noticeable, too. Estimation to implement this: 1 day, 1-2 persons, requires GitHub knowledge and access to horde3d.org.

Regards,
Christoph

I haven't done profiling. As it is a fairly low level engine, I cannot compare it to h3d without adding highlevel code. It is something like the egRendererBase part of h3d with multithread support (separate submit/render threads), it supports sorting the renderqueue. And egTexture with some texture file/format support. and debug text rendering. Maybe it is not the best engine, but it is better than egRendererBase in it current form for multicore machines. Probably could contain bugs, but the maintainer is very helpful, after some chatting about our needs he added pvr/ktx etc1/pvrtc1 support in 3 days.


I also wouldn't be happy to leave Horde3D. Probably I will finish the iOS,android port on github. It needs mainly some shader fix and pvr/ktx texture loading. If anyone would like to be a collaborator on github feel free to tell me.