Priority for fixing painting?

Tuan, can you let me know if you have it on your list of todos to fix the texture painting for PLM2 and if so, when you think you'll get to it?

Thanks

It's on Top of TODO, but as I'm busy on real life things til monday don't expect it finished before monday night. I'll try to add that 2 pass shader too.

I've made some modifications on CVS today, but just InstantBaseEdit works, still have some work on other edit texture modes.

Okay, thanks for the update. This is great news

Made splatting2Edit and splattingShader to work in CVS. (at least with texturestretchfactor=1, doesn't have time to test with different value.)

Sweet!

Still doesn't seem to be working for me. I see that you've taken out the MISSED_SPOT define?

It *seems* to be a bit better in that it's not drawing random garbage everwhere, but I'm painting at a certain position on the terrain and it's updating a completely different page roughly the same as what I'm drawing but slightly different as if the brush is stopping at certain tile edges and not painting over the boundary between two tiles.

I need to get you looking at it in GOOF Editor so you can really see what's going on.

Something that has changed in the PLM2 has also broken my terrain deforming as well, probably with the painting change. Again, hard to explain, but my previously my deforming was working nicely with me setting up the BrushArray manually and passing a brush strength value. Now when I deform it shoots up a huge pillar of pointy terrain in some places and does nothing in others.

Have you had a chance to check out the SVN code for GOOF and run it?

Just a quick note - what seems to be happening with the deforming is that when I deform the terrain, it might be deforming more strongly than it was before, and additionally the terrain goes super low resolution on whatever page I deform. When I load the terrain up again (reload the map) the deformed areas look okay (the lod problem doesn't exist after I reload) but the strength of my brush seems to be much stronger than expected and deformed more than before.

Still doesn't seem to be working for me.
That's weird. here it works on every maps I checked... using custom brush or predefined crater brush.

Have you had a chance to check out the SVN code for GOOF and run it?
Yep. have to compile the beast now...

Something that has changed in the PLM2 has also broken my terrain deforming
True, there was an inconsistent handling of array that was sometimes scaling it with ScaleY, sometimes with BrushScale and sometimes none of it.
Now it is always scaled by both.
That way you'll have consistent HeightField set/get, with value that should be in [0,1].

Have you had a chance to check out the SVN code for GOOF and run it?
binary dll/lib won't do as they need vc2003 dll run-time dependency. (libnoise, openal, boost.) So I'm downloading,compiling them asap.

Managed to make binary work.
(had to replace all dependency dll too (cegui, devil, zlib))

Still have to find how to paint/deform using UI.

Ok. manage to paint and therefore reproduce the bug.

It paints but not at the good place, indeed. (and border tile are not working, but that may be because it thinks it paints on landscape border.)

Confirmed about bad impact point.
you didn't set TextureStrectchFactor in your default map

TextureStretchFactor=2


So it believes it was 1.0ff and therefore was wrongly updating texture as it was thinking it was 2x smaller and therefore painting was wrong.

So set it in PagingLandscapeEditorPlugin::writeTerrainConfig and in your defaultMap.cfg.

Now that this is fixed, I'll try to add a 2 pass shader TextureMode tomorrow.

Ah, I figured that 1.0 was the value it should be

Why 2.0? Thanks for solving!

Woot, painting is working with your fix! It's not taking my brush sizes at the moment, but I'll look into that now.

The deform is still messed up though. Were you getting the same thing as I am? By the way, the deform options window is beneath the paint options window in the paging landscape tool - they're overlapping. I have to fix that

Here are screenshots:

Pre-deform:



Post de-form:




As you can see it's doing something strange going to very low res pages and not just the page I deformed (I've zoomed back on the second shot but haven't changed the position of the cursor)

binary dll/lib won't do as they need vc2003 dll run-time dependency. (libnoise, openal, boost.) So I'm downloading,compiling them asap.


Damn, I'll include the source in the SVN for these projects as well with instructions on compiling. Damn damn damn.

Also, I've changed the brush strength to fall between 0 and 1 for the slider and that doesn't fix it.

*EDIT*

Fixed the problem, see bottom for details.

*END EDIT*

Sorry for spamming you, but here's some more details:

I have texture painting working very nicely now, with the paint window letting you select from the 4 splatting textures which switches the paint channel that you're painting.

Update to the latest version. Unfortunately however, I have also just starting using Boost.FileSystem so you'll need to have that lib also compiled from Boost.

One thing about the painting and how it blends the layers together to equal 1 - something unexpected is happening. Let's say the layers look like this:

Layer0 - dirt
Layer1 - rock
Layer2 - grass
Layer3 - snow

If dirt is the zero layer and you paint rock down in a patch over the dirt, and then paint grass over the same spot, it "erases" the original rock back to dirt and then paints grass over it.

Actually it's basically like any channel you paint always subtracts from all channels except for channel 0 - so if you paint rock, grass or snow it always blends to dirt.

Here's screenshots:





*EDIT*

Fixed the problem by making changes to OgrePagingLandscapeTexture_Splatting2Edit.cpp and will probably have to be made to all others as well.


const uchar AlphaChange = (uchar)abs((int)previousValue - (int)BaseData[ curr_image_pos ]);


The uchar was wrapping around from 0 back to 255 in the case where previousValue - newValue < 0, so was giving funny results. This seems to fix it. Take a look for yourself if you want.

*END EDIT*

2.0f because you call call Maputil mapsplit with 2.0f in your code. (last parameter I think.)

About painting I still have to fix some things, but it will indeed be something like that.

Also, I've changed the brush strength to fall between 0 and 1 for the slider and that doesn't fix it.
deform problem Must be related to the new terrain tile roughness cache config. cache doesn't seem to renew after modification.
I'll check that out.

About painting I still have to fix some things, but it will indeed be something like that.


The insoluble question is as follow :

Which channel to lower when he raise one ?


After several tries and tought. I think it should really users should defines all channels he want to put in at once (as in Color painting.)

Otherwise it gives complex code and I'm not sure user would like results.

So I'll add a setOption("PaintChannels") which will receives a std::<float> of factors, asserting that results all factors summed = 1.

Much more user-friendly and logical, no ?

Huh?

If we wanted to give users full access over what they're painting, we'd do what Freeworld does and have the layers always overlap each other and the user paints or erases from one layer at a time. We don't want to do that as it's not as natural as simply choosing a texture and painting it regardless of which layer it is.

The way I've done, which takes the alpha delta of layer being painted and subtracts it from all other layers seems to work fine in practice.

An array of ints? Hardly sounds like something I'd want to use. How would I present that to the user as an option in an editor, for example?

The way I've done, which takes the alpha delta of layer being painted and subtracts it from all other layers seems to work fine in practice.

But it ends in Sum(alphas) != 1.0f

And some fine painting work is impossible directly... (50%dirt50%grass) when terrain is previously (30%dirt30%grass)


An array of ints? Hardly sounds like something I'd want to use. How would I present that to the user as an option in an editor, for example?

An array of Reals, each Real being a value between 0.0f and 1.0f.
Could be presented as slider under each texture ?

Honestly I can't imagine using it that way, can you, realistically?

Does it have to sum to 1.0? Is that something particular with how the shaders work under the assumption that it sums to 1.0? Because it works fine with multipass currently, but I can understand if the pixel shader needs that for part of its shading.

The fact is that if the user is painting channel 2 over something, they're mostly concerned that

a) the channel 2 texture is more visible than what was there previously
b) what was there previously is still partially visible until you paint fully opaque over that area.

So if we add to the alpha of channel 2, and subtract equally from other channels so they still equal 1.0, then I'm sure it's adequate. Most of the time (90%?) you're blending one texture over another, not really worried about blending 4 perfectly in one area.

About fine painting - if we wanted to get the user complete control we'd do the layers thing as Freeworld does - where layer 0 is always on bottom, layer 1 is always over it, layer 2 is above 1 and 0, etc. and when you paint you can paint or erase the alpha of a single layer at a time. If you want grass (layer 0) to display over rock (layer 1) you have to erase the alpha of Layer 1 for the grass to shine through. In this case, while editing the layers they wouldn't add up to 1.0 (you could use splatting2edit) but then do a post-process to recalculate all the alphas to sum to 1.0 (you could work from the top layer down and figure out what the values should be) and export alphas in the proper range.

I'm not saying we should do that at all - I think it's a bad idea. I'm just saying that's one of best ways to give exact control to the user.

I think the best way is to still figure out how to get the current way to work without the user having to choose from a set of sliders for each layer.

Honestly I can't imagine using it that way, can you, realistically?
It's not hard, It's exactly like when painting.
Try painting instantbasetexture.

It's the other I can't imagine really use. Just tried with freeworld, and it's very hard to tweak and produce desired result.

Just to point out : both are possible using my proposition and it is simpler to implement

alpha of channel 2, and subtract equally from other channels so they still equal 1.0
That's where the problem aris. You have to find/code there a solid complex algo that solves that. Problem arise when some channel does out of [0,1] and therefore falsificate the 1.0f sum, you have to re-pass until you equally repartionned, all that for each point painted...

Is that something particular with how the shaders work under the assumption that it sums to 1.0?
If you blend to 1.0f one channel and not moving other... result is not guaranteed by d3d or gl spec. For example, they can just continue to be visible if first channel is 1.0f and other are blended afterwards with factors > 1.0f too.
And that would happens nearly always.
User would have no other way than go over each channel, draw on it to make it 0.0f, then re-select channel he wanted and paint over.

The fact is that if the user is painting channel 2 over something
There's no problem with that, it's just a particular case of my proposition, you select your channel 2 by making an array of Float like {0.0f, 1.0f, 0.0f, 0.0f} and you paint still using the Brush to make nice transition.

My proposition can do :
- Paint a single channel.
- Sum Being equal to one is assured.
- User would be able to grain-specify a mix of splat like {0.3f, 0.1f, 0.5f, 0.1f}. Like when selecting a custom color in gimp palette.

Okay, this is above my head for some reason so I'll asume you're the expert and go with your advice.

What I want is to be able to have the user pick a channel, and paint that texture onto the terrain over top of whatever was there. If they painted down grass and want to paint dirt over it - with nice transition along the edges of the brush where the strength of the brush is less (due to the brush array) - and it should work, regardless of what order the layers are in. If your solution works for that, then great.

I also want the user to be able to choose a strength for the brush - if the user wants to have an area with 50% grass and 50% sand, I doubt they'll want to move the slider to 50 for grass and 50 for sand and 0 for rock and 0 for dirt and then paint. More likely they'll want to slide the brush strength up to 100 and choose grass texture and paint it down, and then choose dirt, slide the brush strength to 50% and paint down dirt over it. See what I mean?

Clay

For example, download this demo and try terrain painting:

http://www.larabie.net/ogre/GOOFEditorDemoMay25.zip

It works very nicely, however this is using splatting2edit so it's multipass and doesn't have the same limitations of doing it in a fragment program.

If we can get it so that it functionality works like that for shaders as well (the painting is very easy), I'd say it would be the best solution.

I doubt they'll want to move the slide
Sliders was a suggestion, it you feel UI that propose only each channel 1.0f is better for user, you're the one that choose (and probably better ui master than me). Btw, that could be done using a "picker".

See what I mean?
Yes, and that's exactly what you'll be able to do.

btw, on cegui wiki there's a "dialog framework" on saving/restoring dialog position. could be handy...

For example, download this demo and try terrain painting:

http://www.larabie.net/ogre/GOOFEditorDemoMay25.zip

It works very nicely, however this is using splatting2edit so it's multipass and doesn't have the same limitations of doing it in a fragment program.

If we can get it so that it functionality works like that for shaders as well (the painting is very easy), I'd say it would be the best solution.

LOOKS polished, but 9 times out of 10 when I try to paint the terrain, it raises the terrain or does nothing, even with the highest brush strength.

You have to choose "paint" from the toolbar, as it starts in "deform" mode.

You have to choose "paint" from the toolbar, as it starts in "deform" mode.

Wow, how did I miss that . Looks good

Ok got it working using new scheme, but there's some interface breaks.

It will be "PaintCenter" for all. (no more PaintColorCenter or PaintAlphaCenter) and "setPaintChannelValues" to specify factor. (no more channel selection before that.)


mChannel = 0;
channelValues.reserve (4);
channelValues.resize (4);

channelValues[0] = 0.0f;
channelValues[1] = 0.0f;
channelValues[2] = 0.0f;
channelValues[3] = 0.0f;
channelValues[mChannel] = 1.0f;
mSceneMgr->setOption( "setPaintChannelValues", &channelValues);

And that will work on any splatting texture mode soon. (painting color is nearly the same. channelValues being RGBA colors in color case.)

I'll let you know when committed, have to fix the deformation cache problem first.

I don't think this is going to work how I want it to work still, but I'll give you the benefit of the doubt until I check it out.

Can users paint exactly how the GOOF editor demo paints by me specifying 1.0 in the proper channel?

Does it work with the brush array providing brush values? It seems like the answer should be "no" since you've actually made the problem more complex by adding weights across multiple channels...

To me it looks like you're asking the user to specify the exact blending values for each and every pixel that gets painted. Am I wrong?

Committed.

Please have a try. If you find it bad, I'll add your solution.

New way still work with brush values. ( in fact, It was brush values + keeping sum to 1, that made previous problem a sort of "gordian knot", as it was "sum readjustements" that breaked the blending factors from brush and sometimes make brush wrongly applied.

Okay, will look at it now

Um, I'm getting an error just trying to run the GOOF editor which loads my default map when the terrain starts rendering, DirectX9 error presenting surfaces. I have a crappy 3d card in this laptop so it can cause problems when a shader is being used that isn't supported, or something else.

Did you change anything that might cause this? I stepped into the code and splatting2edit texture is being created and I don't see anything particularly wrong with it.

I'm about to try it out on my other comp.

Try with splattingshader until I check this.

Works fine, I'm happy with it in SplattingShaderEdit and setting only one channel at a time to 1.0f.

Nice work!

I don't yet have the UI to allow sliding different channel values. Can't run SplattingShader on my laptop because the 3d card is garbage though.

On my other comp with GeForce 6800 it doesn't display the terrain at all when in SplattingShader2Edit so the geometry must be invalid or something wrong with material and that's why it crashes on the laptop.

Also, deforming is working now, however I think the brush strength is only usuable between 0 and 0.1 - anything higher and it deforms too fast. I guess it also depends on the frequency I call setOption("PaintCenter", ...) however I'm calling it currently about 10 times per second, something like this:


mBrushLastUpdate += evt.timeSinceLastFrame;
if(mLeftMouseDown && mBrushLastUpdate > 0.1f)
{
mSceneMgr->setOption("PaintCenter", &mBrushPos);
}


There's also some pretty bad page (or maybe tile) border problems with the splatting shader that I didn't notice with the splatting2edit material.

Another thing I noticed when I first loaded up was the terrain was still pretty low res in certain places where it should have had higher res - places where I'd deformed the terrain. This was as if the max pixel error was being ignored. As soon as I deformed the terrain a little more in that area it resumed a nice LOD.

brush strength is only usuable between 0 and 0.1
That's the way to make small deformation.
( brush strength * float value in brusharray) = terrain value, max being 1.0f, you can end up very fast to a 1.0f value.

the splatting shader
yes, have to check that.

Then I first loaded up was the terrain was still pretty low res
Was because of the *.info.cfg cache filed up when cache didn't update on deformation, thus being wrong until a new deformation applied (or if you erase manually the *.info.cfg)