Horde3D

WARNING!!!
You may need to read up a bit on DarkTree for this post to make sense.

First, I've just started working with Horde, I discovered it a while back but it's just now really starting to come of age (a rather happily lightweight age).

What I'm looking at doing is a DarkTree rendering class which would hook up to the DarkTree engine (obviously)(which is free by the way) in the utilities library. I don't see any foreseeable hangups in just rendering out to flat textures that could be applied to quads and the like. Looks like less than a week's work, plus some to make it nice and clean.

However, what's bumbling my brain is that it'd be really nice to be able to use the object space (or single sample of world space) coordinates of each pixel of the object.

So my question is if there's an obvious means to render out the object/world space colors to a texture matching the assigned UV coordinates? Or can I by some means lock the shader from updating and render out the flat image?

I looked into doing it CPU side but ultimately thought, "Why? I can't name a 3d package off the top of my head that can't bake out object space normals." So an alternative would be to bake them traditionally. Even if you had an object space bitmap, and an RGBA "splatting" style map for different darktree outputs you could get away with reduced resolution by just upsampling and blurring if need be, x2 size would yield good results and x4 may even be acceptable in some cases.

If there's a means by which I can avoid the 3d package baked object space map and instead just have the appropriate RGBA blend maps I would be delighted. My primary objective is to maintain artist control of mesh textures (through the RGBA maybe multiple RGBA blend maps) but greatly reduce the required idle disk space consumption.

------------------------------------------------------------------------

Additionally, is such functionality a welcomed addition to Horde? I would like to contribute my work if it is of interest as procedural content can help to reduce the resource consumption associated with high detail graphics as well as reduce the amount of time involved in content creation.

Progress:

http://img262.imageshack.us/my.php?imag ... st2wk3.jpg


http://img262.imageshack.us/my.php?imag ... estzs0.jpg


Here's some darktree textures rendered to a quad in Horde.

Only the DarkTree files exist on the harddrive, the textures are generated and immediately loaded into memory.

Currently a diffuse, normal, and specular textures are generated.

No noticeable impact for rendering 10 darktrees during scene load. Darktree material usage currently works as a hardcoded override. It shouldn't take too much work to cleanly fit it as a definition in XML.

EDIT:: Switched to Thumbnails to be friendly.

Hi AcidFaucet,

sorry for my late reply. I'm currently quite busy with development (also on a still to be announced major feature that I think many people will appreciate ).

Generally such a procedural texture library is very welcome! It is great to see that you are making good progress so quickly. It should also be quite easy to bring dynamic (animated) image data to the engine. We have several projects now which use dynamic resources (especially textures but also animations) like a live video stream from a webcam. Achieving this is simple (just a few lines of code) but might be not directly obvious, so if you want that and have problems here I will outline the approach in more detail.

I haven't looked into DarkTree yet so I'm not completely sure if I understand in which way you require object space normals. My guess is you need them to do some blending based on the geometry, similar to mixing textures for terrain based on slope? This would be simple in the shaders (you have access there to the normals in tangent, object and world space) but this would mean that you have to procedurally create a texture and additionally a shader which is probably a plenty of work. Hmm, currently there is no function to access the normals of meshes but that should be easy to integrate (access to vertex positions is already possible).

Keep up the good work, I'm very curious to see more

This isn't an easy task... I think that the way that 3D programs do this is to render each polygon of the model one-at-a-time. When rendering each poly, you would have to construct an ortho camera pointing directly at that poly, then take the output of the render and copy it to the correct place in your final bitmap...


A much easier (but flawed) way would be to simply render the object as usual with a shader that outputted the object/world-space positions, and the texture-coordinates to different MRT's (e.g. buf0.rgb = world-space position, buf1.rg = texture co-ords). If you render the object from multiple angles with such a shader, you could then use the resulting bitmaps as an associative-array, which could be used to re-assemble the final bitmap using the CPU. The only problem with this approach is that any occluded pixels will be missing from the reconstruction...
e.g. to reassemble the rendered data into the final texture:
[EDIT]

Yes, I'm very interested in this! Procedural textures are great, especially with the amount of high-resolution content needed for next-gen artwork!

@DarkAngel
Texture baking certainly is looking like a nightmare undertaking. For the time being until I've got everything cleanly integrated (it's still 90% hack) and working using externally baked maps I'll reapproach the issue hopefully the wiser.

Next step is to get the rendering working in Horde through all the conventional means (XML, etc) instead of being hardcoded. Stuck on a couple of hangups that have me itching to stick in a virtual function where I really should find another way.

Then its on to Demo-time before returning to baking.

XML Material Addition specs thus Far:
Currently DarkTreeFlat is all that's implemented and working.

<DarkTreeFlat unit="texUnitOutput" file=".dsts" channel="from the dsts" sizeX="pixels" sizeY="pixels"/>

<DarkTree3d unit file channel posMap="perpixel positions" sizeMod="variable to all the posMap to be upsampled"/>

<DarkTreeBlend map="RGB/A blend map">
<DarkTreeFlat />
<DarkTree3d />
<DarkTreeFlat />
<DarkTreeFlat / >
</DarkTreeBlend>

Blend assigns the texUnits to an RGBA channel for blending multiple darktrees into a single texture.

<DarkTreeMultiChannelFlat />
<DarkTreeMultiChannel3d />
These allow multiple channels to be used, being assigned to RGBA of the output texture. An example would be to include Luminance, Transparency, Specular Intensity, and Reflection in the RGBA channels.

A multiplier will also be available someplace to make it global but more easily accessible as a configuring tool. If the multiplier is 0 the procedurals will render at the specified resolution, if 2 they'll render at twice that, and if at 4 they'll render even larger. I figured it would be necessary to provide a global detail control of some type.

I'll try to get an executable demo up for download in a few days, I'm fortunately recovering from breaking my neck a while ago so I've got plenty of time and should have something releasable codewise before Christmas.

I'm way off schedule. I blame Crysis, and a snag with the resource manager (which is not a problem with the resource manager, just a problem with procedurally produced files being managed).

I don't think I'm too terribly far away from cleanliness, but I'm going to have to sit on until next week arrives.

The resource manager is not yet perfect for dynamic resources and I would like to do some improvements quite soon. If you have some ideas don't hesitate to tell me. Nevertheless great to hear that you are coming forward (even if not as fast as you would have wished).

And of course I hope that you will get well soon with your neck injury!

I'm making rather good progress now. Necessitated changes to what I had in mind for the XML, but they're for the better.

Everything still needs to get put through its paces to make sure nothing breaks. I inherited from Texture2dResource and made the necessary changes (different load and update functions along with an extra struct of data for the DT renderer).

Current performance is less than optimal as for each texture load I am initializing darktree, rendering, and then destorying it. This is fine for 1 or 2 textures but in the case of 30 or so, it's wasteful. It's useful though for cases where resources are being loaded singly in a paged fashion.

So pending work is: error checking and console warning spitting, and a variant to the loadResourcesFromDisk function in the utility lib that pools together all resources of the procedural texture type before loading them using a single instance of darktree (which will get the benefits of darktrees internal threading).

After that it's all just feature completion for object space normals, blending, saving images to file and loading from file if the file really exists, etc.

No time for a screenshot, it's almost new year.

Each resource type has static init and release functions. You could do the DarkTree initialization and release there.

Some of our current thoughts are going towards Horde3D 1.0
We plan to make the engine a bit easier to extend, possibly by implementing a simple plugin system. I'm currently doing some internal clean ups and smaller refactorings to make adding new scene node types more convinient (although I think it is not too bad at the moment). If you have any ideas about what could be improved in this area don't hesitate to tell me.

Beautiful.

I should have seen that given that there's big bold letters right above the two functions in doxygen.

I hope it is ok that I have moved this topic to the new development forum.

It sure is.

No this isn't dead. Expect to see something once 1.0 is in release status instead of Beta. (well maybe a bit after, but not too much)