PROPOSAL: Box-mapping support and the completion of the BGE-candy features

The following in mainly aimed at those who were who were working on the BGE-candy branch because they know a bit of OpenGL code.

Many months ago, the BGE community witnessed the birth of a promising project to upgrade the engine’s graphical capabilities known as the BGE-Candy branch, everyone was excited, but as of now unfortunately we saw it fall by the wayside which led to people thinking that the hope for arealight and translucency support is dead.

Here’s what I’m thinking, we at least get the current features of the BGE-candy branch to a trunk-ready state and get those merged in, and along with that see the birth of box-mapping support for textures (which, along with full-coordinates support would allow textures to be mapped across objects rather than per-object, which would really enhance the graphics for Minecraft-like games and other games where level geometry is generated).

Now I know that one of the developers is working on a voxel-based renderer for the BGE, and I don’t mind that at all. The only thing was is that we saw these exciting features developed that could go in by the next release only to see them dropped in favor of this long-term project that will take a while before it’s in a testable state, so it would be nice if they found the time to develop at least a small selection of graphical goodies for each release. (I don’t care if it’s just one or two, just something that will enhance the BGE in the very short-term while the long-term projects are underway). I don’t know if the arealight feature would get in the way of Kupoman’s inferred lighting project, but there are other choices that can be tackled.

To note about the box mapping, I’ve before spent hours trying to get something like that to work with nodes, and all my attempts have either wound up with textures being stretched to oblivion in certain cases, skewed to a extent and misaligned, or in a recent case restricting the effect to the exact center of the scene.

So those are my personal thoughts anyway, comments?

I can always resolve conflicts in the Harmony branch, so people should not be too worried about getting in my way. Just as long as the changes aren’t getting in my way because the feature was poorly developed. If you need help developing a feature, let me know on these forums or o IRC (I tend to hang around a few blender related channels on freenode, including #blendercoders and #bgecoders).

I would love to see those area lights make their way into Trunk.

Also, regarding the request for built-in boxmapping support, I can back this up by the fact that nearly every possible way of trying to do it with nodes is hindered by one or more caveats that dramatically decreases its usefulness.

Take this for example (an attempt to build it with nodes).
bge_boxmap(1).blend (629 KB)

You can see that it looks fine as first because it was textured with no UVmaps, but move and rotate the cube and you find that even these more sophisticated setups have some major drawbacks. (in this case it’s only working when it’s in the center of the scene, in other cases, you can make the masks using orpho data to allow it to work with movement, but not rotation).

Either way, the combination of limited vector possibilities compared to the Cycles node system and the fact that global/orpho coordinates working just one way means there’s little hope for a high quality workaround that won’t make your head spin in terms of complexity.

I hope you can see what I mean.

Hi,

I see no reason that the area lamps couldn’t be committed any time, unless Martins is still working on it. Most of the things I have been doing in Candy are partial implementations, and have, as you said, been placed on hold with the voxel rendered taking it’s place. Also, I think martins had added some different mapping things to candy, which might include box mapping (?)

But I really don’t see a reason why we can’t have these goodies which can be developed in the space of one release cycle because it’s going to be a while before the voxel-renderer is production-ready.

And with some like the box mapping, these are features that could even help with the games you are developing now, a crafting game in Blender that uses it would mean it would have a graphical feature that Mojang has never even considered.

And it’s not only for crafting games, games that involve the random generation of geometry could benefit from it as well. (imagine having totally seamless texture transitions between pieces because of the fact that the edge of the texture tile will never be right along the edge). It would also increase quality in cases whereas if one decided to apply random morphs to the geometry using shape keys (which is possible through the use of the function that re-instances the physics mesh).

I’ll see if I can catch martins online tomorrow and I’ll talk to him about committing some things to trunk.

Might not be the right place to ask, but:

How about also pushing some features of Harmony to trunk?
Like:
→ support for geometry shaders
→ support for multiple render passes
→ GUI and such for easier GLSL usage

Aren’t those ready to use already?

Would be nice to see all those little pieces that are already there, ready and waiting, to be integrated into trunk.

All you need to do is make the object-space normal work as advertised in the shader nodes, then you can do all the blended-box mapping (and similar effects) you want. Right now, for same reason all normal outputs deliver the view-space normal.

Urfoex:
Those features work, but they are not quite Trunk ready yet. There is a fairly large list of minor bugs that need to be fixed.

@Kupoman.
I see.
Too bad.

Do you have the issue list somewhere open so others could help you?

Urfoex:
The list is currently on a notepad at my desk. If someone is interested in giving me a hand with Harmony, I can post the list to my wiki page.

Did you get hold of Martin in the end?

I discovered that this can already be done with the UV Project Modifier, you just use six projectors, empties rotated so that the -Z axises converge ortogonally (two for each axis, XYZ)


Make sure that you have a existing UV map for your objects, and leave image blank in the modifier. This way you can manipulate the mapping with the empties. The texture can be different for every object they will be specified in the material as normal, since you leave image blank you only affect the UV map :wink:


Hey Mokazon, any word on whether you managed to get a hold of Martinsh on getting the global coordinate functionality and the like to trunk since you last replied?

Thanks.