Feature requests

[aeonios]

(With apologies to gajop for derailing his thread)

sigh. Have a look at this thread and tell me again that 3d applications like z-brush/mudbox and to a lesser degree blender is not good for terrain...
http://www.polycount.com/forum/showthread.php?t=125857

Well, that stuff looks great, but it's an apples to oranges comparison. 95% of that stuff uses full 3D deformations, but heightmaps in spring only support deformations in one dimension (Z, assuming Z-up). It might be possible to do some of that stuff in spring, but some of it is impossible and most of it is pretty much impractical from a performance standpoint. I'm not aware of any spring map with that level of detail or special 3D features like rock arches either.

This has never been my experience, it handles cases like this easily and paint response is fast. also painting large terrains by hand is a PITA, use procedural materials.

Meh, well there are several reasons why that might be. You might/probably have better hardware than I do, you might be using a different blender version, or perhaps better settings, but I haven't been able to get it to perform well given any of the settings I've managed to tinker with so far. I wasn't able to paint sea of dunes in blender hardly at all, even at 1/4 the vertex count and given the relatively small contrast in the terrain height.

I dislike procedural texturing, it tends to create maps that are ugly and/or generic. There are a few exceptions where you might be able to get away with it, but I consider it to be lazy at the very least. I agree about the PITA part though, but super huge maps aren't very playable/don't get played anyway. Another exception would be worldcreator worldmachine, which apparently has advanced capabilities for making things look like rocks, dirt, etc. Smoth's maps are like that, but I'm not entirely sure whether I like the way that looks or not, and either way worldmachine is not free.

EDIT: Well I read through the old thread on cattle and loveplay and now I understand that WM does that because smoth made it do so and for no other reason. Also idk, WM may have a free version, don't know how usable it is though.

The setup is very simple, and does render fast because it doesn't require bells and whistles. has more control because you an use more than a base grid mesh to create the z-depth pass. for instance rocky mountains need a road? simply extrude a path down a spline and you get a smooth base

There are probably lots of ways to create that effect. I'm not sure that extruding anything in blender would be my first choice though. Editing a height map in SME or something along those lines is more like painting, whereas modeling in blender is more like working a complicated machine. Specifically though, a machine designed to manipulate things in 3 dimensions whereas we only need one here.

loading a heightmap and info maps from an image on demand

The premise to build a toolchain with plugable components is more valuable than shoehorning everything into one tool and doing an average job of it.

Find out what the industry vets are doing and do something similar.

Avoid NIH

My point was that a tool for making spring maps could be better for making spring maps by specializing for the limitations and possibilities that they present, compared to a tool made for more general work, much of which is extraneous for map making. Not to mention the extra skills required for using programs like blender; just figuring out how to make texture paint work for maps was an incredible chore and required learning most of the interface. Importing maps is still a chore, for that matter, and can be a pain if you happen to change parts of it in other applications.

There are certainly instances where external tools are better or more appropriate, but at least for terrain and texture you can't really get much better or more WYSIWYG than an in-game editor based on the actual implementation the game uses.

And so many sighs... I wish I could simply mind meld and get all this back and forth over with.

Be careful what you wish for. There's a reason vulcans had to throw away their emotions.

[enetheru]

its is clear we are on different wavelengths, and as such I will not derail the conversation more

[gajop]

Some of the things you mentioned are actually implemented already.
These are the hotkeys: http://gajop.github.io/Scenario-Editor-Core/faq.html
Basically, once you're in either height or texture mode you can change size with ctrl + mouse wheel.
If you're modifying the heightmap you can change the mode by pressing 1-4.

I know this isn't obvious at all yet. Adding the GUI for this is planned.

The texture/height editing interface is too simplistic for lots of tasks, and height in particular doesn't have enough features for even doing basic stuff.

Feel free to say what you found lacking and I'll try to get it implemented.

It seems to only have one fuzzy circle brush though,
no scale control for the textures (which may or may not be needed, but is nice to have)
and no control over blending strength.

I'd appreciate if you could go into more detail here.

It also seems to perform well

The way it's currently implemented it's really fast - much faster than the heightmap modifying functions.

Also, undo/redo doesn't seem to work for texture paint

I'm aware. I need to clear up that code before implementing it, and the implementation of that is likely to be harder.

and it might even be good to have seperate undo/redo stacks for each mode (ie texture paint, height, unit/feature placing, etc), although that requires having clear modes that you can shift between and know what will be undone/redone.

This is not planned for now. It's hard to implement and might be confusing to use. First thing I need to add an undo/redo list where you might have an idea what's going on.

Height needs way more controls (brush size, height scaling, mode), the ability to use different brush shapes, etc. There's also no way to make cliffs atm (ie no equivalent to 'set' mode in SME). Support for editing metal maps, terrain type maps etc is also important, but should be fairly simple compared to height and texture and none of those require layers or anything else fancy.

What is "mode"?
Adding strength to all these commands is planned.
"Set" requires additional UI to specify the number, and since editbox is broken in ZK until this PR gets merged it's not usable for "Scenario Editor ZK" yet. That said, it should function in the same way as "Level" imo, but rather work with a predefined height instead.
Metal map editing is planned, but I might be limited by the engine.
Terrain type maps = grass/features? Features you can edit already, grass editing is planned (I keep saying that, don't I? )

Overall I think it's kind of silly to try to implement a program when you don't really know how it will be used. Some of that is much harder to explain than it is to learn simply by doing. There's lots of reasons I'd rather be using scened instead of SME, too, but that's also hard to understand unless you've actually fought with SME and its interface in the context of actually trying to make a map.

I've played a bit with some programs that are used for this purpose, but I've no time to become a professional map maker. I'm capable enough of seeing what needs to be added by looking at pros at their work or having this sort of feedback.

I also had it crash several times. The worst was under spring 98, which doesn't seem to work for it at all, but I also got a crash under spring 91 when trying to place a wreckage for a mystery unit from ZK. I haven't really used it enough to track down specific problems though.

I'd like to ask you to send me infologs for this . Since you'll be using the git version, can you also include the commit versions of both your Scenario Editor Core, Scenario Editor ZK and the ZK version you're using? (The alternative is to verify you're on the latest versions before submitting).

Why re-invent the wheel

I'm trying to avoid that as much as possible. I'm already loading/saving height and texture maps and I'll look into making a (better) interface for that next.
That said, I think that there are two major reasons why a good in-game editor that does at least basic map editing is needed:
- New users are much more likely to get started with something that is integrated within Spring than to use a wide variety of third party programs and relatively complex toolchains.
- It's important to have WYSIWYG while you're editing maps. No tool other than an in-game one could present how it's going to look like accurately. The lack of units, features, spring effects and it not being rendered by the same set of shaders will make it harder to fine tune things with a third party tool.
- (Personal goal) Eventually I want to play with shaders to add animated terrain and it seems a lot easier to do so if it's an in-game tool.

[enetheru]

Real feature request:
If you do load and save of height map already can you add a checkbox to 'update when file changes' so that i can have a dual monitor setup to sculpt in blender on one window, and have spring open in another.. save my height map and spring auto loads updated version.

[gajop]

I'm pretty sure Spring doesn't support any file-change notifications or reading just the file's modification date so I'd have to re-read the entire (or substantial portion) of the file every once in a while and verify if it's the same.
This can be inefficient, but I'll try and see if I can do it.

[Silentwings]

A "re-read the heightmap from file" button would work almost as well, I guess (at least for me), and would be easier to implement.

[gajop]

Yeah, that's doable

[aeonios]

Some of the things you mentioned are actually implemented already.
These are the hotkeys: http://gajop.github.io/Scenario-Editor-Core/faq.html
Basically, once you're in either height or texture mode you can change size with ctrl + mouse wheel.
If you're modifying the heightmap you can change the mode by pressing 1-4.

I know this isn't obvious at all yet. Adding the GUI for this is planned.

Ahh, now it's starting to make sense.

The hotkeys bother me a little. Mainly, control+mouse wheel is used for tilting the camera, at least for COFC, which means you can't use camera tilt in texture or height mode. Other cameras not so sure.

Having right click deselect the current brush really threw me off too, since in SME left click is used for raise and right click for lower in height, and I don't think right click does anything in texture. I think shift+mouse wheel would be better for brush size control, and right click for lower. Having redundant ways to deselect is kind of silly.

The texture/height editing interface is too simplistic for lots of tasks, and height in particular doesn't have enough features for even doing basic stuff.

Feel free to say what you found lacking and I'll try to get it implemented.

Bigger maximum brush size would be a good start. Infinite would be best! Interfaces for showing current size and other details are important too.

It seems to only have one fuzzy circle brush though,
no scale control for the textures (which may or may not be needed, but is nice to have)
and no control over blending strength.

I'd appreciate if you could go into more detail here.

Well brush shapes to start with. Different brush shapes are used for different things in different modes (ie height vs texture). In texture you might use brush shape to create scattered patterns, or maybe as a stencil. For height the brush shape/intensity map is used for defining the terrain shapes the brushes produce, and is used for things like making mountain shapes, sand dunes, cracks, rivers and anything else you can think of.

Texture scaling, in blender you can use textures of arbitrary size and even non-square tileable textures. I've got some that are ridiculous sizes like 2048x and even larger that have details much too large in scale for maps, but in blender you can rescale them on the fly without having to edit the original image. It's convenient, but not strictly necessary.

Blending strength I think you mentioned you were planning to implement already, which would make texture paint really awesome even without anything else.

It also seems to perform well

The way it's currently implemented it's really fast - much faster than the heightmap modifying functions.

Super duper fast. Even with the largest brush on a big map it's still nice and smooth.

This is not planned for now. It's hard to implement and might be confusing to use. First thing I need to add an undo/redo list where you might have an idea what's going on.

Very true, also lower priority.

Height needs way more controls (brush size, height scaling, mode), the ability to use different brush shapes, etc. There's also no way to make cliffs atm (ie no equivalent to 'set' mode in SME). Support for editing metal maps, terrain type maps etc is also important, but should be fairly simple compared to height and texture and none of those require layers or anything else fancy.

What is "mode"?

Ah, the stuff you currently have tagged to num1-4.

Adding strength to all these commands is planned.
"Set" requires additional UI to specify the number, and since editbox is broken in ZK until this PR gets merged it's not usable for "Scenario Editor ZK" yet. That said, it should function in the same way as "Level" imo, but rather work with a predefined height instead.

Ah. That sounds about right though. I was thinking you could implement 'level' a second way, too, using contrast reduction instead of sharp flattening. That would work more like smooth than like set, and could be useful for things like the mountain roads eneth mentioned earlier. The way it works currently is still useful though, so that would be an addition and not a replacement.

Metal map editing is planned, but I might be limited by the engine.

Thinking about it that might present problems with zk as well, since it uses a special metal spot detecting gadget. On the other hand that same gadget also might be useful for certain things in scened too though, like lining up metal spot graphics with the metal spots. We'll see I guess.

Terrain type maps = grass/features? Features you can edit already, grass editing is planned (I keep saying that, don't I? )

Hmm, those too, but there's another map that specifies terrain type. You can customize different terrain types in mapinfo.lua with different hardnesses, unit speed modifiers, etc. It's just called a 'type map'.

I've played a bit with some programs that are used for this purpose, but I've no time to become a professional map maker. I'm capable enough of seeing what needs to be added by looking at pros at their work or having this sort of feedback.

I jumped to conclusions there based on only a fraction of your actual implementation, I apologize.

I'd like to ask you to send me infologs for this . Since you'll be using the git version, can you also include the commit versions of both your Scenario Editor Core, Scenario Editor ZK and the ZK version you're using? (The alternative is to verify you're on the latest versions before submitting).

I'm not entirely sure where to find the commit version number, but keeping up with the latest isn't really an issue. Do you want the infologs for 98 as well or just the 91 crashes? (I also need to recheck that and make sure it wasn't just something I did and not 98 specifically)

- (Personal goal) Eventually I want to play with shaders to add animated terrain and it seems a lot easier to do so if it's an in-game tool.

I've heard legends about stuff like this. I don't understand much of it though.

[gajop]

Ahh, now it's starting to make sense.

The hotkeys bother me a little. Mainly, control+mouse wheel is used for tilting the camera, at least for COFC, which means you can't use camera tilt in texture or height mode. Other cameras not so sure.

Having right click deselect the current brush really threw me off too, since in SME left click is used for raise and right click for lower in height, and I don't think right click does anything in texture. I think shift+mouse wheel would be better for brush size control, and right click for lower. Having redundant ways to deselect is kind of silly.

Alright, this can be easily changed. I'm not really looking to use SME as a point of reference though.
A professional scenairo/mapmaking tool like worldmachine/blender, SC2 & D:OS scenario editors and similar are of more interest imo.
How do they do it?
I guess ESC as cancel is enough.

Bigger maximum brush size would be a good start. Infinite would be best! Interfaces for showing current size and other details are important too.

For the height editing, I can't increase the size with the current implementation due to performance reasons. For texture it's doable.
That said, texture editing will become slower when undo/redo gets added there.

Well brush shapes to start with. Different brush shapes are used for different things in different modes (ie height vs texture). In texture you might use brush shape to create scattered patterns, or maybe as a stencil. For height the brush shape/intensity map is used for defining the terrain shapes the brushes produce, and is used for things like making mountain shapes, sand dunes, cracks, rivers and anything else you can think of.

Would like some examples of this. What should I google?

Texture scaling, in blender you can use textures of arbitrary size and even non-square tileable textures. I've got some that are ridiculous sizes like 2048x and even larger that have details much too large in scale for maps, but in blender you can rescale them on the fly without having to edit the original image. It's convenient, but not strictly necessary.

Texture scaling sounds easy (as these are opengl textures), but there's probably something I'm missing here

That would work more like smooth than like set, and could be useful for things like the mountain roads eneth mentioned earlier.

Since I already have smooth, how different would it be from it? Maybe smaller gaussians?
Basically smooth with options?

Hmm, those too, but there's another map that specifies terrain type. You can customize different terrain types in mapinfo.lua with different hardnesses, unit speed modifiers, etc. It's just called a 'type map'.

Oh, ok, so nothing visible. I'll still check it out though, but it seems like a slightly advanced feature as it's not rendered.

Do you want the infologs for 98 as well or just the 91 crashes? (I also need to recheck that and make sure it wasn't just something I did and not 98 specifically)

All crashes are wanted. If it's a full crash where Spring also dies, it might be an engine issue, but if it's just Scenario Editor that's dead, it's probably something that's persistent in the current Spring version as well.
There are bugs, especially since the LCS and chiliui updates.

I've heard legends about stuff like this. I don't understand much of it though.

Think of it as editing zerg creep. It's basically editing textures that get passed to shaders and animated. I always wanted to make a POC out of that, because it just sounds awesome.

[aeonios]

Alright, this can be easily changed. I'm not really looking to use SME as a point of reference though.
A professional scenairo/mapmaking tool like worldmachine/blender, SC2 & D:OS scenario editors and similar are of more interest imo.
How do they do it?
I guess ESC as cancel is enough.

Well, normally I wouldn't recommend SME as a model for much of anything, but it does do a few things right. The best part though is just that it's simple, at least for that case. I'll check out galaxy soon and let you know if I get any cool ideas from it.

For the height editing, I can't increase the size with the current implementation due to performance reasons. For texture it's doable.
That said, texture editing will become slower when undo/redo gets added there.

Hmm, that could be a problem. SME's max brush size lets you cover over 1/4 of a 20x20 map. Granted though, you don't exactly do fine detailed editing that way, and a bit of lag is probably acceptable.

Well brush shapes to start with. Different brush shapes are used for different things in different modes (ie height vs texture). In texture you might use brush shape to create scattered patterns, or maybe as a stencil. For height the brush shape/intensity map is used for defining the terrain shapes the brushes produce, and is used for things like making mountain shapes, sand dunes, cracks, rivers and anything else you can think of.

Would like some examples of this. What should I google?

"height map brush"

Texture scaling sounds easy (as these are opengl textures), but there's probably something I'm missing here

it probably is easy. Dunno about scaling quality though.

Since I already have smooth, how different would it be from it? Maybe smaller gaussians?
Basically smooth with options?

Not gaussians at all, but reducing contrast. In other words, reducing or increasing the brightness of pixels that are different from the average. Smooth doesn't exactly flatten, unless used at very high strength. Reducing contrast is much more direct. Of course, I've never seen a contrast reducing brush either, so I don't know how practical that would actually be.

Alternatively I could be full of crap. I need to test that some.

Hmm, those too, but there's another map that specifies terrain type. You can customize different terrain types in mapinfo.lua with different hardnesses, unit speed modifiers, etc. It's just called a 'type map'.

Oh, ok, so nothing visible. I'll still check it out though, but it seems like a slightly advanced feature as it's not rendered.

This is another thing that SME does pretty well. It actually uses a color for each type so you can see what you're doing, but you have to use a special view mode to see it.

All crashes are wanted. If it's a full crash where Spring also dies, it might be an engine issue, but if it's just Scenario Editor that's dead, it's probably something that's persistent in the current Spring version as well.
There are bugs, especially since the LCS and chiliui updates.

Well, I wasn't able to reproduce crashes I was getting with 98, but some of them still remain that were also in 91, and one was fixed in 98 that crashed in 91. Basically if you hit the folder icon in the texture panel your ui crashes in 91, but not in 98. Apparently clicking any unit/wreckage/feature in the panel crashes your ui in both, not sure if that's unique to scened-zk.

Spring itself also crashed when exiting game in 98, which is kind of strange since it doesn't do that otherwise.

98 infolog: http://pastebin.com/RgiHJD1Z
91 infolog: http://pastebin.com/GKCyh5ci

Think of it as editing zerg creep. It's basically editing textures that get passed to shaders and animated. I always wanted to make a POC out of that, because it just sounds awesome.

Ah, that makes sense. The question is what could it be used for in practice?

[gajop]

Hmm, that could be a problem. SME's max brush size lets you cover over 1/4 of a 20x20 map. Granted though, you don't exactly do fine detailed editing that way, and a bit of lag is probably acceptable.

Even the simplest tool like level simply takes too long to execute for a large brush, probably due to the heightmap changes causing pathing to be recalculated. I'm afraid I'll have to go to the engine to optimize this at a point.. but it's likely to be too much work for now.

Well, I wasn't able to reproduce crashes I was getting with 98, but some of them still remain that were also in 91, and one was fixed in 98 that crashed in 91. Basically if you hit the folder icon in the texture panel your ui crashes in 91, but not in 98. Apparently clicking any unit/wreckage/feature in the panel crashes your ui in both, not sure if that's unique to scened-zk.

Spring itself also crashed when exiting game in 98, which is kind of strange since it doesn't do that otherwise.

98 infolog: http://pastebin.com/RgiHJD1Z
91 infolog: http://pastebin.com/GKCyh5ci

The "crash on exit" is a thing Spring has had for ages and it's not considered a high priority to fix.
I've just "fixed" the two errors you've received.
Sorry for this mess. This has been caused by a recent update of the Lua class library system I'm using. Since the entire project depends on it, I just haven't gotten around to testing it all yet.

If you use it too long you might get a crash because there's not enough memory. Currently limiting the undo stack in memory size hasn't been implemented so be aware of that (no need to report it).

Ah, that makes sense. The question is what could it be used for in practice?

You'll just have to wait and see =)

[gajop]

Hey, mind trying it (texture editing) again?
I've fixed a few bugs and added undo/redo, blending, property selection, modes and some better looking textures.
Blending is only enabled for the "Normal" mode -> I want your feedback on other modes without blending on first to see if any of them make sense. Personally I found useful: Normal, Lighten, Darken and for the zalgo effect: HardLight, SoftLight and Overlay modes. Difference and InverseDifference also seem usable, while the rest aren't really.
Would appreciate if you can be as detailed as possible regarding this.
Otherwise I've not got much to add there for now

I also found a lot of really decent looking textures but I'm not sure whether it should really be included into Scenario Editor Core (they're kinda big). I definitely want users to have a set of things to use even if they don't pick a specific game. Feedback on those presently added is appreciated. You can see them in the "tiles" for the normal textures and "detail" for the detailTex. "old-tiles" contains previous textures which I might get rid off eventually (I'm not too happy with how they look).

The next major release will be themed to map editing, you can follow it here: https://github.com/gajop/Scenario-Edito ... tone%3A0.5+

NOTE: Your PC might not have enough memory after prolonged usage due to the undo/redo stacks being unlimited atm.

[enetheru]

could you add a button to clear the undo stacks as a work around for now?

also can you paint the shading textures? ie splat distributions, normal map, specular etc etc.

[aeonios]

Hey, mind trying it (texture editing) again?
I've fixed a few bugs and added undo/redo, blending, property selection, modes and some better looking textures.
Blending is only enabled for the "Normal" mode -> I want your feedback on other modes without blending on first to see if any of them make sense. Personally I found useful: Normal, Lighten, Darken and for the zalgo effect: HardLight, SoftLight and Overlay modes. Difference and InverseDifference also seem usable, while the rest aren't really.
Would appreciate if you can be as detailed as possible regarding this.
Otherwise I've not got much to add there for now

Woah, that was quick. Add/subtract can be useful sometimes, add is used for making glow effects at least. I say leave it as is, for those people who know more about what those things are for. Colorize is also useful, but it needs a plain color selector in order to make sense.

One thing I want to figure out is how people do banded contour colors, ie Titan. I was planning on something like that for my next map, seems like a good time to figure out how to make it work and if anything extra is needed.

I don't understand how the 'detail' tab works, or what it's for. o_O

I can also confirm that everything seems to be working as it should be now. The 98 crash on close seems to be an engine thing, which I never noticed before since ZK ran on 91 up until recently. Texture editing lags a bit at first now, but I haven't noticed it being any slower in use and undo/redo does work properly. All the new settings for textures seem to be working as expected, too.

I also found a lot of really decent looking textures but I'm not sure whether it should really be included into Scenario Editor Core (they're kinda big). I definitely want users to have a set of things to use even if they don't pick a specific game. Feedback on those presently added is appreciated. You can see them in the "tiles" for the normal textures and "detail" for the detailTex. "old-tiles" contains previous textures which I might get rid off eventually (I'm not too happy with how they look).

A few of them are ok, although I'm not sure what all of them are. The labels tend to get squashed out in the interface window.

Also, here's my collection as-is (fair warning: 170MB): https://www.dropbox.com/s/mrg4hp4zwrfsb ... es.7z?dl=0

[gajop]

could you add a button to clear the undo stacks as a work around for now?

Although trivial to do so I can just as easily hardcode the limit - I don't want people get frustrated by forgetting to clear stacks :D
Realistically I'll add it when I do this: https://github.com/gajop/Scenario-Editor-Core/issues/20

Regarding this, I have discovered two different memory limits for me:
- The Spring defined Lua Memory limit that's around 800MB which can be reached through if doing excessive heightmap modifications. Adding a lot of units/features might also trigger it, but far less likely.
- The memory limit of the system (this can also vary if Spring is 32bit or 64bit). This is the real limit of any texture editing, as it seems Spring doesn't count them as "Lua memory" (please don't patch this). I was pleasantly surprised to see Spring also using my RAM to hold FBO textures. Seeing as I have 16GB RAM and and additional 2GB VRAM I never hit this limit.

The Lua memory limit seems too harsh for what I'm doing. I don't want to start using textures for storing heightmap/unit/feature data as a way around it.

also can you paint the shading textures? ie splat distributions, normal map, specular etc etc.

I want to, but I'm not sure I can currently. The easy way to achieve so would be to modify Spring to support it. The hard way would be to use custom textures and shaders to *render* the map.
What I currently have available is:
Spring.GetMapSquareTexture from https://springrts.com/wiki/Lua_UnsyncedRead#Rendering -> to get the Spring diffuse(?) textures
Spring.SetMapSquareTexture from https://springrts.com/wiki/Lua_UnsyncedCtrl#Rendering -> to set the Spring diffuse(?) textures
Once I've obtained the original Spring textures and copied them to their FBO-enabled Lua counterparts, I'm just rendering to new ones.
I don't see a way to edit the other map types.

Even if I could, the question is then how this should be done. Ideally the material itself should specify all the maps. The users could also modify them via custom modes (e.g. a mode to increase/decrease specular).

One thing I want to figure out is how people do banded contour colors, ie Titan. I was planning on something like that for my next map, seems like a good time to figure out how to make it work and if anything extra is needed.

OK, I'll try to play around with contours. I'll see how this should be best approached.

I don't understand how the 'detail' tab works, or what it's for. o_O

I'm not sure the detail tab or the detail texture scaling should be presented to the user...
Basically when you paint, three (four if you include color which isn't in yet) are used:
- Existing map texture
- Paint texture (the most important thing you choose)
- Detail texture: at different scale than the paint texture and multiplies with it so patterns become less obvious (it's basically noise). You can try experimenting with different detail textures and/or scale to see how it works.

I could instead maybe add some sort of shapes instead (or in addition) to the detail texture? For the average user, it makes more sense to be choosing that.

Texture editing lags a bit at first now, but I haven't noticed it being any slower in use and undo/redo does work properly.

It's certainly a bit slower because of undo/redo, but it seems "fast enough" for me. That is, unless you paint the entire map in one go and then want to undo + redo that.
I try to optimize things due to the perceived importance, and so far it's going as fast as it needs to be imo.

A few of them are ok, although I'm not sure what all of them are. The labels tend to get squashed out in the interface window.

Hehe, yeah, I didn't rename any of them yet. I'll also see to it that tooltips are added if there's not enough room to display the title.
Everything used here can be seen outside of Spring in: /LuaUI/images/scenedit/brush_textures/ (in Scenario Editor Core)

Also, here's my collection as-is (fair warning: 170MB): https://www.dropbox.com/s/mrg4hp4zwrfsb ... es.7z?dl=0

Those look pretty awesome. I'd like to include some of them as the default (maybe I'll make a separate repository for this and make it a dependency). What's their licence like?

[aeonios]

Even if I could, the question is then how this should be done. Ideally the material itself should specify all the maps. The users could also modify them via custom modes (e.g. a mode to increase/decrease specular).

FYI, specular maps for mapmaking use RGBA and not 8-bit intensity like units do. They're also stored as a standalone file rather than 'compiled'. I don't really know how splat maps work though.

OK, I'll try to play around with contours. I'll see how this should be best approached.

Awesome.

I'm not sure the detail tab or the detail texture scaling should be presented to the user...
Basically when you paint, three (four if you include color which isn't in yet) are used:
- Existing map texture
- Paint texture (the most important thing you choose)
- Detail texture: at different scale than the paint texture and multiplies with it so patterns become less obvious (it's basically noise). You can try experimenting with different detail textures and/or scale to see how it works.

Ah, I thought of doing something like that, but found that mixing/layering textures sufficiently achieves the same effect. I'll have to mess with that some more to see if/how it might be useful.

I could instead maybe add some sort of shapes instead (or in addition) to the detail texture? For the average user, it makes more sense to be choosing that.

Brush shapes are important anyway, I'll let you know on that though.

Hehe, yeah, I didn't rename any of them yet. I'll also see to it that tooltips are added if there's not enough room to display the title.
Everything used here can be seen outside of Spring in: /LuaUI/images/scenedit/brush_textures/ (in Scenario Editor Core)

Is it possible to resize that window, or any of them? I haven't really figured out how to customize it, if so, but tooltips should definitely be the default. I think the UI could use some simplification/streamlining overall anyway. It gets kind of cluttered with 3+ panels.

What's their licence like?

I'm pretty sure all the ones I sent you are CC, and a lot of them came from opengameart. A few were never intended to be used as art, but I'm pretty sure all of those are public domain. Some of them may not have been converted to seamless, you may need to double check that, but you can do whatever you want with them otherwise. Some may also need to be scaled down to fit well within the scaling limits of scened, which I'll probably eventually get around to doing anyway. If you decide to split that off I wouldn't mind helping to maintain that.

[gajop]

Is it possible to resize that window, or any of them? I haven't really figured out how to customize it, if so, but tooltips should definitely be the default. I think the UI could use some simplification/streamlining overall anyway. It gets kind of cluttered with 3+ panels.

I've disabled resizing in most places. GUI will be redone, but currently I'm just looking to get the functionality in.
I want to avoid a hugely complicated menu that some editors have, as it tends to drive newbies away. It would be great if something similar to the current tabbed menu system would be the "entry point" to the editor.
Anyhow, great take is needed to design the UI correctly and it's not something I want to do for this milestone. Mostly because I myself am not sure how the process works, where as the UI should be designed to be both user friendly as well as allow highly efficient editing for power users.

I'm pretty sure all the ones I sent you are CC, and a lot of them came from opengameart.

Are they just normal CC or some sort of NC, SA, ND or something of that sort?
I'd only like to use the normal CC as I'm not sure how those restrictions would apply to map making, and it's one hurdle I'd like to avoid.
Public domain or similar is ofc great.

If you decide to split that off I wouldn't mind helping to maintain that.

That would be great!
The question is just how to include it with scened. A separate github repo that's pulled in as a submodule might be easiest for now.
Github still has a 1GB repository limit, but I think we're fine for now :)

[aeonios]

I've disabled resizing in most places. GUI will be redone, but currently I'm just looking to get the functionality in. I want to avoid a hugely complicated menu that some editors have, as it tends to drive newbies away. It would be great if something similar to the current tabbed menu system would be the "entry point" to the editor.
Anyhow, great take is needed to design the UI correctly and it's not something I want to do for this milestone. Mostly because I myself am not sure how the process works, where as the UI should be designed to be both user friendly as well as allow highly efficient editing for power users.

I figured so, although I don't think it'll be as difficult as you're thinking.

Are they just normal CC or some sort of NC, SA, ND or something of that sort?
I'd only like to use the normal CC as I'm not sure how those restrictions would apply to map making, and it's one hurdle I'd like to avoid.
Public domain or similar is ofc great.

Grass-green, grass-litter, and all the sand textures except for sand-smooth it turns out are not compatible. The sand textures are CC-BY, which is technically compatible but an obnoxious license overall. The rest are all either CC or equally liberal.

That would be great!
The question is just how to include it with scened. A separate github repo that's pulled in as a submodule might be easiest for now.
Github still has a 1GB repository limit, but I think we're fine for now :)

Hmm, I don't think we should ever run over that. "Scened-Textures" gogo?

[gajop]

"Scened-Textures" gogo?

For consistency with the other modules I've named it Scenario Editor Resources. Give me your github username to add you.

I've added the initial set of textures. Now I need you to check their licences and cleanup the repo.
Ideally the licence of each file should be known.

Feel free to rename the files and folders, although try to keep all the textures in one top folder for now and make sure all licences reflect the rename changes. This is a bad/lazy example of how it should be done.

Ideally the actual licence should be copied too, but sometimes that wasn't obvious from the start

[gajop]

Oh another thing. I've removed some of the non-tiling textures.
I want to keep this repository lean and clean. The fewer and better looking textures, the better!
Users shouldn't be spending time choosing from one of the 50 grass textures, but should still be able to produce stuff with enough variety.
I don't want to put an exact number on it.. There's about 100 currently, so let's aim at no more than around 200-300 for now?
PS: You can also add any shapes or detail you might find