Horde3D

As a way to keep the Horde3D community on the same page in regards to the development of future features, this Community Roadmap wikipage will keep an up to date log of the undergoing activities. While community management features like Trac and Bugzilla are helpful, we are still a small community and should take full advantage of the forum as a hub for all horde3d development communication.

(The page still needs some styling and content)

It is my hope that this thread will be used as a discussion page that will lead to assignment/volunteering, and discussion of implementation details.

Just some things about organization:

I'd propose one Wiki page per issue, with all being linked at that central page, then we've got a better place to discuss each issues in the discussion pages.
Also what we need is not only a roadmap but also some kind of bug list (those things won't go into a roadmap, I currently think about "Horde3D needs more comments in the source itself (like doxygen) for writing extensions with it.").

Edit See Thread: Compressed Texture Support - Support for DDS, PowerVR, and other Texture formats.

I would recommend that you use the bug reports forum for the time being.

It's great to see the roadmap.

I have some experience with d3d9 so maybe I can help with this, but I haven't used OpenGL for a while.
Is anybody working on this?
I saw that pablito3dartist has made a d3d10 port but i don't know anything about its current state.

Development cycle: I like how Ogre handles this, with a stable and an experimental trunk so the members can check the progress of the new features and comment on it (help with the development).

There was interest from a forum member Bob to do a D3D10 backend, and others have also expressed interest, but as long as that Assigned to filed is left unchecked it is pretty much an interest and not a commitment.

Afaik there is no D3D10 backend, can you point me to a repository or binary download?

Submission of patches should be enough. I think this is how it is done in Ogre also. There are 4 devs on SF.net that can merge the changes into the proper branches.

I also like that idea. I'm thinking of an experimental branch where many more community members have write access. It would be sort of evolutionary: Perfectionism is not a hard requirement, a feature or fix can be checked in and improved by other members. When it has the desired quality and is proven it can go in the main branch. I think that could really help to speed up progress and would make development more community based and agile. It would also free the core team from having to review and integrate single patches all the time. I would really like to try if that works out.

Would anyone want to host and manage such an experimental/community branch? I don't think that it is a good idea to use the SF svn for that.

I'd propose trying out git or mercurial for this. Then you could more easily just create a community repository. (Also git does feature easy replication of svn repositories).

I'd be up for creating a git mirror of svn.

EDIT: The problem here would be that it does not allow checking out from SVN though...

I think hosting an extra public SVN at our old university in Augsburg shouldn't be a problem. Although I think it shouldn't be a problem to create a public testing branch in the SourceForge SVN, too. Keeping all sources at one repository might be more easy to manage. Concerning git or other version control systems I don't have any experience so far.

Greetings from Portugal

Mercurial is very easy to use, and similar to svn. I use mercurial exclusively on my own projects.

This would make branching and merging much easier

Would make it more difficult than with git or mercurial, at least when both repos are the same
(you can branch between multiple repos way more easily there)

The problem with a branch on sf.net are the access rights, you cannot set them as fine-grained as needed.

Btw, if you are going to do that, I'd like to be under those who have access