Horde3D

Well, not much progress on this lately. I have been working on destructible, volumetric terrains in the mean time, and right now am trying to accomplish a headless install of debian on my server box. Hopefully I will be returning to this very soon though

_________________
Tristam MacDonald - [swiftcoding]

Unfortunately, having just acquired a dev machine capable of running this, I find that although the code still compiles against the latest Horde, it doesn't actually work. All I get is a black screen with the fps text - and a fair mount of debugging indicates that the triangles are being drawn, so I have to figure something broke with the shaders, despite no warnings there either.

Edit: turns out not a version problem, as I rolled back to the original version of Horde I had been developing against with no change. Maybe a difference between Apple and ATI's GLSL implementations?

_________________
Tristam MacDonald - [swiftcoding]

Are you using GLSLs random number generators? I haven't used them myself, but I hear that some implementations just always return 0.

Nope, it is all fairly vanilla stuff. My though was that if it would run on apple's crappy drivers, it should run anywhere - but apparently not. Of course, the other possibility is that I broke something a few months ago, and never fixed, but I don't have any notes that would indicate that.

edit: curiouser and curiouser. glIntercept shows that all my textures are generated correctly, and all my shaders compile and link successfully. Horde is certainly rendering, since the HUD comes up. My render function is definitely being called, and the planet is definitely on screen - but all I get is darkness.

edit 2: and fixed. Turned out some of the vertex shader trickery I was performing just wont work on this card/driver - namely passing altitude in to the vertex shader in gl_Vertex.w, and linearising the depth. No idea why they don't work, but it was only for an atmosphere experiment anyway.

I have also managed to upgrade back to the SVN version of Horde with no troubles. However, after I modified a couple of shaders, I noticed that the log always tells me about successful compilation, even though the renderer always fails to set the material - any ideas on this one?

edit 3: turns out that the names of the shader contexts didn't match the shaders, so the problem contexts were never even compiled - good to know for the future.

_________________
Tristam MacDonald - [swiftcoding]

Now I am back on the quest to get rid of depth buffer precision problems - with a notable lack of success.

I reworked the renderer such that the view matrix is always identity, while the view matrix is pre-multiplied by the model matrix, which causes all world space shader operations are actually in view space. One of Sean O'Neil's articles indicated this could help with precision, but I don't see much improvement - I think I need to transform each patch separately (at the moment all patches are given in the planet's coordinate system.)

I also set up so that the planet is internally translated and scaled such that it is always 5000 units from the camera, so i can leave my near/far planes set to 1.0 and 10,000.0, respectively. While this simplifies a lot of calculations, it doesn't seem to help as much as I would have expected, and also screws up frustum culling.

In order to manage all the patches as child nodes of the planet node, and also to fix the frustum culling with scaled distances, I think it is time to move the planet renderer out of core (so to speak). Presently the planet renderer is implemented entirely as a Horde extension, with the usual interface to set and retrieve parameters. My intention is to move the bulk of the work out of the extension, into the application layer, leaving only the Horde and OpenGL specific stuff in the extension.

Unfortunately, this really requires that I have full access to the extension class from the application. Either I have to link statically with Horde (introducing undesirable licensing issues), or I have to give Horde the ability to load extensions from DLLs/connect extensions at runtime across DLL boundaries.

_________________
Tristam MacDonald - [swiftcoding]

Is there a special reason why do need to do that?

Horde has a different philosphy/design than other popular engines (like ogre). Horde it is supposed to be a full graphics engine and is designed to act as the game's 3d engine and rendering component or subsystem. So it should take care of all rendering and I think it is rather bad design if some other part of the application is doing rendering. I would also consider accessing the internal classes from the application layer as a hack which destroys to some degree Horde's high modularity and strong abstraction. In contrast to Horde, I consider Ogre rather as a graphics utility library (not to be taken negatively): a tool to build a graphics engine. So it is by definition more flexible than Horde. But to overcome the lower flexibility of the strong modularization and abstraction, Horde has the extension mechanism.

Ja, I agree in principle. My current system works somewhat as you describe: the PlanetNode manages Patches, which are loaded on-demand from the application.

The problem with this is that we are already crossing a DLL boundary, in order to move patches from the application into the extension, which means that I must perform completely separate memory management on each side of the DLL-divide. Also the size of the API is becoming a problem - I have to perform intelligent dynamic caching of Patches, which requires multiple callbacks on either side. Also, a great deal of the procedural generation needs to be done on the GPU, which requires a ridiculous amount of functionality to be either implemented or exported by the extension.

I could potentially move the LOD management, streaming resource manager and procedural generation all into the extension itself, but this seems to defeat the purpose of keeping Horde as the rendering layer - and also introduces the aforementioned licensing issues.

_________________
Tristam MacDonald - [swiftcoding]

You should be able to overload the new and delete operators of the classes which are shared across this boundary.
If a class's new/delete operators are implemented in "DLL A", then whenever "DLL B" calls new/delete on that class-type, they will be called within "DLL A" (and therefore will always be managed within "DLL A"'s heap).

That works fine with a C++ interface, but right now I am connecting the two new implementations with c callbacks. There is also the issue that the page cache uses multiple memory pools, which have to be bridged in a similar fashion.

I guess the main issue is that this extension needs to be largely hosted in one place, and the most sensible place would be the extension itself. However, I have an LGPL conflict, so I can't move that section into the statically linked extension - such is life.

_________________
Tristam MacDonald - [swiftcoding]

So is LGPL issues your main concern and not so much the technical side?

I would be fine with a license that does not require extensions to be open-sourced. The question is only how this could be realized. Something like that users just need to contribute back the changes that they did to the existing Horde3D classes. It could be a dual license (besides the LGPL) but we would need a bulletproof formulation for that.

Ja, I would say that is about right - several of the technical challenges result from needing to keep the LGPL-incompatible code dynamically linked. Note that it isn't sufficient just to keep it dynamically linked either - because of deficiencies in the wording of the LGPL v2 (which have been corrected in v3), I cannot link to templates in the DLL, so the interface has to be procedural (i.e. plain C).

I was thinking a bit a bit about this, and my inclination is that it should be issued as an LGPL exception (similar in concept to stdc++'s GPL-with-exception). My quick formulation looks something like this:

"An exception is hereby granted, allowing code licensed under another set of terms to be statically linked with the engine, and the resulting binary to be distributed, provided that this additional code implements the engine's extension interface, and makes no changes to the engine beyond the scope of the extension mechanism. This code need not be licensed under the LGPL, and the terms of the LGPL are not applied to it. This exception in no way weakens or removes the obligation to release any and all changes to the engine itself under the terms of the LGPL."

_________________
Tristam MacDonald - [swiftcoding]

The license discussion is continued here now: http://www.horde3d.org/forums/viewtopic.php?f=8&t=640

Great thread, interesting results.



How did that go? I run into problems with debootstrap trying it the other day myself, setting up software RAID 1, so in the end used an image which left me with var partition of 4.3 gig, and home 64gig! and plesk requires it to be the other way round. Now running CentOS5 which is remarkably like FC which I came from

_________________

Let's bring 'em out! Any old iron! Any old iron!
A door opens and a homewife brings out a rather sophisticated-looking ground-to-air missile system, and dumps it on the cart.
Thank you.

Debian installed great once I found a monitor to plug in, but the headless install was a no go. The box is an old PowerPC Mac, and the boot firmware doesn't match the descriptions on the web, so booting the installer in the first place was impossible without a monitor. Debian seems to be the only large distro with decent powerpc support?

_________________
Tristam MacDonald - [swiftcoding]

Can't say ive had any experience with a powerpc as per-say, but im surprised theirs no other distro's to support it? Yes, the headless install of Debian seems pretty rubbish, doesn't help that Ubuntu Server falvour doesn't support kickstart fully, or prescript (which others do).

_________________

Let's bring 'em out! Any old iron! Any old iron!
A door opens and a homewife brings out a rather sophisticated-looking ground-to-air missile system, and dumps it on the cart.
Thank you.