Scape: Terrain editing on the GPU [Src+Demo now available!]

[N0vember]

Well it doesn't have a default constructor, it wants a material and a number of instances, I guess the material is easy but the number of instances may be a tricky parameter that depends on some capabilities ?
The instance number is just used at this line :

assert(instanceIndex < getSupportedInstanceCount());

So it's just a limit.
Looking into HeightfieldOperationGPUPage, it seems the tickActive function will fire until there are still brush instances in the list, and getSupportedInstanceCount just determine the max number that will be processed during one tick.

Maybe it had default values that got lost in the way ?

[frostbyte]

yeah, i also suspect code on github is not the compiled code...
i think maybe it just needs to add explicit default constructor() inhertance all way down to the base...
but i don't really know, haven't looked at the code too much...

[jacmoe]

Bitbucket .. or did you find one on the hub?

[jacmoe]

It is odd that getFirstHeightfieldBuffer is nowhere to be found.
And that GPU2DOperationQuadBrush could work with a seemingly non-existing default constructor.
..
It was compiled with vc9, the original code, btw.

[frostbyte]

sorry.... bitbucket...

[N0vember]

I found the answer
This file simply was never compiled. Because it can't.
I looked in v1.0 source and the file is not part of the VC solution. Probably the same in current source ?

(EDIT) Check, it's not there either in the v1.1 VC solution.
A quick find tells us the "HeightfieldOperationGPUPage" class is not referenced anywhere in the solution

So it was probably a work in progress or a stub that got renamed, but it's not needed to compile the source.

(EDIT 2) To push the investigation further, I think it was a stub of what then became HeightfieldOperationTaskPageGPUBrush, you can see in the code and inheritance hierarchy.
So yeah, you don't need it, and I think the feature is there, just in another class !

[jacmoe]

Thanks for the hint.
I painstakingly compared the dirs and the project includes and has now renamed/removed them.
Awesome!

[jacmoe]

I would have hung myself in desperation without your help NOvember.

[frostbyte]

NOvember. +1 for saving jacmoe's life...
too sensitive for this cruel cruel world...

[frostbyte]

hmmm: what about all the libs that integrate with ogre:terrain? eg: hydrax,recast,bullet, terrain lod, light/shadow etc..
anyway this terrain renderer can represent/disguise itself as regular ogre terrain?

[jacmoe]

First: it's for Ogitor, not Ogre.
Second: Ogitor will read and write in Ogre Terrain format. Or any format you want.
You don't need to worry about what runs under the hood.
It won't break anything.

[frostbyte]

You don't need to worry about what runs under the hood.

not worried but i would love to see this inside apps/games as well..
i can think of some cool effects...
so again in case you missed me editing my post:
anyway this terrain renderer can represent/disguise itself as regular ogre terrain?

[jacmoe]

It should be able to since it's just a renderable.
And it doesn't need to be paged.
You can read about it here:
http://www.decarpentier.nl/scape-render

[frostbyte]

already started...thanks...i'll stop nagging( for now... )

edit: ok, found a hint in a previous post...

I have no plans to integrate Scape into Ogitor, as my time on Scape is already limited and I know nothing about the Ogitor or Ogre::Terrain. But it should be doable, as design-wise Scapes's terrain renderer (in the Engine/HeightfieldGeom folder) is largely decoupled from the terrain editor. The first thing that would have to be created is a way to sharing the internal buffer, requiring Ogitor to use the HeightfieldBuffer, Scape to use Ogitor's version of it, or (perhaps preferably) creating a new version of HeightfieldBuffer that acts like an efficient adapter to Ogitor/Terrain's representation. But, again, I've no experience with Ogitor/Terrain so I might be completely wrong here, and I don't plan to do this myself. But if someone else would want to give it a go, I might be able to give a few more pointers.

[duststorm]

The ogitor team picking this up again: music to my ears!

[jacmoe]

Progress:

Running under Ogre 1.10 ('default'), CPU and GPU brushes works

[nevarim]

great work

[Herb]

@jacmoe - Do you have these changes somewhere on bitbucket to play with yet? I see the old bitbucket repo without changes since 2012 here (https://bitbucket.org/gdecarpentier/scape). Any plans on adding this repo (or forking it) on the ogreaddons with your changes?

[EDIT] - Sorry, I see the Scape repo now under ogreaddons, so I'll poke at that!

I'm interested in playing with this more. Is this a completely different terrain format than the current Ogre Terrain? Or is it Ogre Terrain with different algorithms generating the terrain data only? I'm guessing it's the first.