Feature requests - Page 5

Feature requests

gajop's in-engine scenario and map editor

Moderators: Moderators, Content Developer

aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Feature requests

Post by aeonios »

gajop wrote:It's pretty useful as it is imo. It will color any texture which means you don't need a separate texture for each color combination you can think of, e.g. no need for "Red Bricks", "Blue Bricks", "Green Bricks" when all that's different is the color..

I'm using chili's colorpicker, which comes with the alpha channel and works in RGB.
Implementing a HSV picker might not be that difficult, and some sort of HSV-ing might be needed for the Color/ColorDodge modes. It's certainly easier to switch colors in a HSV picker. Will investigate...
Hmm, sounds good.
eronoobos wrote:Sure. However, this will need some new semi-transparent textures to use in this mode. Slightly related, I might also allow painting/stamping in rectangle shapes and not just circles.
Both modes would be useful. In add mode a texture with a black background is as good as semi-transparent. I was thinking of placing fractals using add mode with circle stamp to automagically crop the edges. Images made specifically for that could use a square brush since their edges are already masked out.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Feature requests

Post by gajop »

aeonios wrote:In add mode a texture with a black background is as good as semi-transparent.
Only if the current map texture is also black, otherwise it will add to the existing color.
You really need a semi-transparent texture (like one of the fractals included).
aeonios wrote: I was thinking of placing fractals using add mode with circle stamp to automagically crop the edges. Images made specifically for that could use a square brush since their edges are already masked out.
I didn't really follow this.
aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Feature requests

Post by aeonios »

gajop wrote:
aeonios wrote:In add mode a texture with a black background is as good as semi-transparent.
Only if the current map texture is also black, otherwise it will add to the existing color.
You really need a semi-transparent texture (like one of the fractals included).
Black = 0.0,
x + 0.0 = x

Even close to black is nearly invisible, as with the laser-floor looking texture I added to fractals.
gajop wrote:
aeonios wrote: I was thinking of placing fractals using add mode with circle stamp to automagically crop the edges. Images made specifically for that could use a square brush since their edges are already masked out.
I didn't really follow this.
If you reduce the size of a circular brush but keep the size of a texture with a circular pattern the same, the edges are smoothly removed by the brush falloff.


I finally got the chance to try out the new features you added recently. Metal and grass editing seems to be blind, and I can't tell if it's working at least. Both of those also need an intensity setting.

Brush rotation and offset seem to be working properly as far as I can tell. For rotation it might be better to use a scale of 0 +/- 180 degrees instead of 0-360, since it's a little more intuitive that way. I think offset should be changed to use a scaling relative to the texture size, ie 0 +/- 100% in the x and y direction rather than absolute values. I thought of a nicer interface for offset too, although it can wait.

I noticed you cleaned up the terrain modes, which is looking good. Set mode works, but I think you should remove the slider entirely and just use text entry for that. Keep in mind that set can use negative values (ie below water level) as well as values well over 1000. For comparison, the cliffs in the map I'm working on are roughly 1200 elmos tall give or take some perlin noise on top. Apparently very large values can crash the engine, but I'm not sure how large.

Based on the response it seems like you're now preloading the brush data when the brush is selected rather than when it's first applied. Texture paint seems to perform a bit better and terrain behaves a little better as well. Changing blend factor or feature factor is really slow now though for whatever reason. I probably don't have the absolute latest version though so I dunno if you fixed that already or not.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Feature requests

Post by gajop »

aeonios wrote: Black = 0.0,
x + 0.0 = x
Even close to black is nearly invisible, as with the laser-floor looking texture I added to fractals.
Let's say the texture you're trying to add has Green and Black, while the background is x.
Black = 0.0,
x + 0.0 = x
^ This is the desired behavior, but the issue is the Green part:
Green = 0,1,0
x + Green = x1,x2+1,x3
So you'll have the extra x1, x2 and x3, instead of just 0, 1, 0.

In the case of semi-transparent textures in normal mode, it will properly set the Green one, while the non-green (transparent) stuff should remain unchanged.
aeonios wrote: If you reduce the size of a circular brush but keep the size of a texture with a circular pattern the same, the edges are smoothly removed by the brush falloff.
I'll see to add the square brush anyway ^^
aeonios wrote: Metal and grass editing seems to be blind, and I can't tell if it's working at least.
Metal doesn't work in ZK, as it doesn't use the Spring metal map but instead something else. This is ZK specific and not planned for now.
Grass editing is visible if you have grass rendering enabled and you have zoomed in at a satisfactory level.
For some weird reason, until you move the camera, some grass changes won't be visible. This is a Spring issue.
aeonios wrote: Both of those also need an intensity setting.
Grass really doesn't. It's a bit map.
aeonios wrote: For rotation it might be better to use a scale of 0 +/- 180 degrees instead of 0-360, since it's a little more intuitive that way.
Probably, easy to do anyway. Btw, you can change it with alt + mouse wheel, and it wraps around (i.e. once you've gone above 360 it starts from 0, and vice versa).
aeonios wrote: I think offset should be changed to use a scaling relative to the texture size, ie 0 +/- 100% in the x and y direction rather than absolute values. I thought of a nicer interface for offset too, although it can wait.
I haven't really thought about this in great detail, but you're quite likely right. Share the idea of the interface.
PS: I kinda want to display the current texture editing settings somewhere, either by drawing it on screen instead of the green circle, or by displaying an image in the window, thoughts?
aeonios wrote: Set mode works, but I think you should remove the slider entirely and just use text entry for that.
Maybe :S Sliders need more work atm, and there needs to be some limits still, even if very large.
As I said before, I kinda want logarithmic sliders, so the size of the slider's values in 1-10 is similar/same as 10-100.
aeonios wrote: Keep in mind that set can use negative values (ie below water level) as well as values well over 1000.
Right click (just like add).
aeonios wrote: Based on the response it seems like you're now preloading the brush data when the brush is selected rather than when it's first applied. Texture paint seems to perform a bit better and terrain behaves a little better as well.
Yep, at least it's something ^_^
aeonios wrote: Changing blend factor or feature factor is really slow now though for whatever reason. I probably don't have the absolute latest version though so I dunno if you fixed that already or not.
It's not slow, this is probably the annoying chili rendering issue I've been experiencing for a year now at least, in multiple projects of mine.
The issue is, chili isn't rendering some components (usually in scrollpanels or layout panels) because it's incorrectly assuming that they aren't in view.
To see it manifest, try scrolling down the terrain editor and modify something through the trackpanel (or editbox). Then (since it probably won't display the change immediately) resize the terrain editor window -> changes are now visible.

I won't fix this in Scened, but rather in chili itself (unless jk does it first).
aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Feature requests

Post by aeonios »

gajop wrote:Let's say the texture you're trying to add has Green and Black, while the background is x.
Black = 0.0,
x + 0.0 = x
^ This is the desired behavior, but the issue is the Green part:
Green = 0,1,0
x + Green = x1,x2+1,x3
So you'll have the extra x1, x2 and x3, instead of just 0, 1, 0.

In the case of semi-transparent textures in normal mode, it will properly set the Green one, while the non-green (transparent) stuff should remain unchanged.
In that case the green part would be the effect you actually want to show up. Small values of color don't add very much, and thus don't change the original texture very much either, while brighter colors look like they're glowing.
gajop wrote:I'll see to add the square brush anyway ^^
I wasn't trying to talk you out of that. :P
gajop wrote:Metal doesn't work in ZK, as it doesn't use the Spring metal map but instead something else. This is ZK specific and not planned for now.
Meh, I figured as much. ZK has special gadgets that override the default metal map overlay. I guess that's one reason to have a game-independent interface for mapmaking. :P
gajop wrote:Grass editing is visible if you have grass rendering enabled and you have zoomed in at a satisfactory level.
For some weird reason, until you move the camera, some grass changes won't be visible. This is a Spring issue.
Hmm, must me on my side then.
gajop wrote:
aeonios wrote: Both of those also need an intensity setting.
Grass really doesn't. It's a bit map.
Technically the grass map uses an 8-bit intensity map and allows for varied intensities (grass thickness), however in practice the resolution of the grass map is roughly the same as individual tufts of grass anyway so it's kind of pointless.
gajop wrote:
aeonios wrote: For rotation it might be better to use a scale of 0 +/- 180 degrees instead of 0-360, since it's a little more intuitive that way.
Probably, easy to do anyway. Btw, you can change it with alt + mouse wheel, and it wraps around (i.e. once you've gone above 360 it starts from 0, and vice versa).
Ah nifty. It needs an arrow on the circle brush or something to show direction, and also alt+mouse wheel adjusts camera altitude, shift+control+mouse wheel would be preferable I think.
gajop wrote:I haven't really thought about this in great detail, but you're quite likely right. Share the idea of the interface.
PS: I kinda want to display the current texture editing settings somewhere, either by drawing it on screen instead of the green circle, or by displaying an image in the window, thoughts?
Ah, I was thinking of a square box like a 2D x,y graph, with the center being default alignment and the extremes left and right being +/-100% in the x or y direction, correlated with the normal +/-x,y dimensions of the graph. Basically you have a point representing the alignment and you just click and drag it around to change it.

Displaying a texture preview instead of just a green circle would be nice, but has complications. Basically if you changed the solid circle to an outline, added an arrow to show the direction of rotation and then display a low-alpha 'ghost' preview of the texture with its proper alignment in the circle, that would give you at least a lot more info about what you're going to get when you paint. On the other hand though the ghost preview would also make it harder to see where you have or haven't painted or how much under the brush, which kind of sucks. I can't think of a good way around that, or haven't yet anyway. I guess you could have the ghost preview toggle with a hotkey, but I'm not entirely happy with that solution.

Also, and just for reference, texture paint in scened is now better/more capable than in blender, at least as far as I know how to use it. It also performs quite a bit better. In its 3D alignment mode blender allows texture offsets but they suck to use, and does not allow rotation control nor any way to adjust the color of the texture.
gajop wrote:
aeonios wrote: Set mode works, but I think you should remove the slider entirely and just use text entry for that.
Maybe :S Sliders need more work atm, and there needs to be some limits still, even if very large.
As I said before, I kinda want logarithmic sliders, so the size of the slider's values in 1-10 is similar/same as 10-100.
4000 is probably a good number. Spring will crash if you exceed some limit, but I'm not sure what that limit is. 4k is a pretty ridiculous height number in any case though.
gajop wrote:
aeonios wrote: Keep in mind that set can use negative values (ie below water level) as well as values well over 1000.
Right click (just like add).
lol why didn't I think of that? >.<
gajop wrote:It's not slow, this is probably the annoying chili rendering issue I've been experiencing for a year now at least, in multiple projects of mine.
The issue is, chili isn't rendering some components (usually in scrollpanels or layout panels) because it's incorrectly assuming that they aren't in view.
To see it manifest, try scrolling down the terrain editor and modify something through the trackpanel (or editbox). Then (since it probably won't display the change immediately) resize the terrain editor window -> changes are now visible.

I won't fix this in Scened, but rather in chili itself (unless jk does it first).
Ah, that does explain what I was seeing. It's probably just because the texture settings window now has considerable scroll to see all the settings. :P
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Feature requests

Post by gajop »

aeonios wrote:In that case the green part would be the effect you actually want to show up. Small values of color don't add very much, and thus don't change the original texture very much either, while brighter colors look like they're glowing.
The point is, you can't really get the effect of stamping if you use use add mode with black background like you would if you used normal mode with transparent background.
aeonios wrote:Meh, I figured as much. ZK has special gadgets that override the default metal map overlay. I guess that's one reason to have a game-independent interface for mapmaking. :P
Yeah.. I think I want to create a game independent map making mod for a couple of reasons. The most important reason being a cleaner interface: no game-specific UI, no scenario editing UI (triggers) but also faster loading time and better stability.
aeonios wrote:
gajop wrote:Grass editing is visible if you have grass rendering enabled and you have zoomed in at a satisfactory level.
For some weird reason, until you move the camera, some grass changes won't be visible. This is a Spring issue.
Hmm, must me on my side then.
Although to be clear, undo/redo doesn't really work correctly with that and I was kinda lazy to correct it - I found both grass and metal maps a bit underwhelming achievements to bother with it for now.
aeonios wrote:
gajop wrote: Grass really doesn't. It's a bit map.
Technically the grass map uses an 8-bit intensity map and allows for varied intensities (grass thickness), however in practice the resolution of the grass map is roughly the same as individual tufts of grass anyway so it's kind of pointless.
I don't think that information is available: https://springrts.com/wiki/Lua_SyncedCtrl#Grass
And also there doesn't seem to be a way to read the grass map info: https://springrts.com/wiki/Lua_SyncedRead (no mention of grass here) -> this makes saving and undo/redo hard.
aeonios wrote: Ah nifty. It needs an arrow on the circle brush or something to show direction, and also alt+mouse wheel adjusts camera altitude, shift+control+mouse wheel would be preferable I think.
Alt-mouse adjust camera altitude? Since when? That's what mouse wheel alone does.
I think in Spring's default alt simple makes the camera slower, but ZK might be different.
I'm really happy with alt-mouse and that'll be the default. I'll allow key bindings, and game-specific editors might have different default key bindings, and also users will be able to specify their own.

The arrow sounds like a really good idea, I'll do that. I wonder if I can also include texture scaling, offset, blend, falloff factor and so on in some way. For example, maybe if the falloff factor is used, the circle would fade out, or in the case of blend, it would be of lower alpha. Some numbers could also be written on the circle. Will think about this (and some of it may not necessarily be on by default, to not confuse the player too much).
aeonios wrote: Ah, I was thinking of a square box like a 2D x,y graph, with the center being default alignment and the extremes left and right being +/-100% in the x or y direction, correlated with the normal +/-x,y dimensions of the graph. Basically you have a point representing the alignment and you just click and drag it around to change it.
Oh, that sounds a lot better (but also slightly harder to implement). I'll look into it.
aeonios wrote:On the other hand though the ghost preview would also make it harder to see where you have or haven't painted or how much under the brush, which kind of sucks.
Yep, that's one the reasons this paint mode isn't available anymore (it used to be available, but I removed it when I cleaned up the texture editing code).
Maybe it could be allowed again by changing some settings if the user really wants to.
aeonios wrote: Also, and just for reference, texture paint in scened is now better/more capable than in blender, at least as far as I know how to use it. It also performs quite a bit better. In its 3D alignment mode blender allows texture offsets but they suck to use, and does not allow rotation control nor any way to adjust the color of the texture.
That's really great to hear, although it needs more work still :)

PS: I kinda figured a way to use "detail" textures. The idea is to use the same texture you're using to paint with, but with different scale. The combination will result in terrain that doesn't have repetitions, although it might look a bit darker (you can later use Add mode with in low blend, with the same settings to make it lighter, although I plan to simply allow for some light multiplication which will either be automatically computed based on the texture, or would be manually set in the terrain window).
Post Reply

Return to “SpringBoard”