Feature requests - Page 3

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 »

My github acct is mtroyka. Some of the non-tiling stuff you removed I can convert to tileable and replace. It takes like no time to do. Some of them I'll probably look for higher quality images.

Tbh I'm not sure how I feel about grass/greenery textures though. They tend to look fake-3D, and it might be better to have more generic grass-colored textures instead. Even cracked mud tends to look bad as a flat texture; I'm thinking of using microterrain for that on my next map, but we'll see how it goes.

Also, I think the detail textures and other special purpose textures should stay in separate directories from the regular texture brushes, to keep that from becoming cluttered. Those directories can then be pointed to directly by the functions that use them. I mention it since I figure changing that might mess with what the code expects currently.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Feature requests

Post by gajop »

aeonios wrote:Tbh I'm not sure how I feel about grass/greenery textures though. They tend to look fake-3D, and it might be better to have more generic grass-colored textures instead.
Indeed. Grass/leaves kinda looks bad. I'm also not too happy with the ice textures, but maybe I didn't use it right. It's OK and even preferable to remove stuff that won't be used.

aeonios wrote:Also, I think the detail textures and other special purpose textures should stay in separate directories from the regular texture brushes, to keep that from becoming cluttered.
Yeah, feel free to change the dirs and I'll update the code when you do. It's an easy change.

Keep in mind that in the future I might have each texture come with an additional specular and normal file as well (that wouldn't be displayed). I might also drop the folder-based categorization and use some data files that assign categories to the images so people can browse/search by tag (e.g. "green", "grass", "futuristic", etc.). This might also include translating all the categories (texture names), and so on. It's just more work and not something planned for the immediate future though :)

What should be looked to is what type of textures are lacking. I don't think there are (m)any futuristic textures like this one for example (although that one is unusable due to the unclear licencing). Don't think there are any mosaics, vitrages, fractals or any indoor man-made stuff either. Try to add some variety there as you feel like it ^^
aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Feature requests

Post by aeonios »

gajop wrote:Indeed. Grass/leaves kinda looks bad. I'm also not too happy with the ice textures, but maybe I didn't use it right. It's OK and even preferable to remove stuff that won't be used.
Yeah, that happens a lot. Make stuff, try stuff, then you find out what works or doesn't. I haven't gotten around to an ice/snow map yet, so I haven't sorted out the good from the bad for it.
gajop wrote:Yeah, feel free to change the dirs and I'll update the code when you do. It's an easy change.

Keep in mind that in the future I might have each texture come with an additional specular and normal file as well (that wouldn't be displayed). I might also drop the folder-based categorization and use some data files that assign categories to the images so people can browse/search by tag (e.g. "green", "grass", "futuristic", etc.). This might also include translating all the categories (texture names), and so on. It's just more work and not something planned for the immediate future though :)
Ugh, blender does that (search by name), but tbh it's terrible. I'd rather search by category than by tags. Ofc the categories work best if they're user defined, but that's another issue. Not to say that search wouldn't necessarily be useful, just that it should be an extra rather than the only way to sort textures.

Multipainting may take some thought as to how to implement it best. In blender 'brushes' are separate from textures, and it might be easier to have 'brush' files that specify what texture, normal, specular etc should be used, with all of those being optional and user-configurable. That would require an extra layer of interface though, and categories would need to be over brushes instead of over raw textures, or they'd need to be over both, separately.
gajop wrote:What should be looked to is what type of textures are lacking. I don't think there are (m)any futuristic textures like this one for example (although that one is unusable due to the unclear licencing). Don't think there are any mosaics, vitrages, fractals or any indoor man-made stuff either. Try to add some variety there as you feel like it ^^
Hmm, high-tech and metal are certainly lacking, but finding good quality textures for that may be a challenge (esp with favorable licensing). I'll keep that in mind though, and maybe ask around once this is organized and sorted a bit better.

Indoor stuff would not be difficult I don't think, but the usage would be kind of strange. How often do you see robots and tanks blowing each other up inside a cathedral? o.O I don't think fractals would look right in general, unless we're talking about perlin noise or something like that, but those types of brushes are special purpose.

I'll probably start adding height brushes and such soon, once I get finished tying up loose ends with some other things I've got going.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Feature requests

Post by gajop »

aeonios wrote:easier to have 'brush' files that specify what texture, normal, specular etc should be used
Yes, technically you'd have "materials" that have their own diffuse, specular, normal and similar textures.
Separately from that you can also specify the shape and modify the diffuse, specular and normal values of the texture using the modes and similar.
aeonios wrote:Indoor stuff would not be difficult I don't think, but the usage would be kind of strange. How often do you see robots and tanks blowing each other up inside a cathedral? o.O I don't think fractals would look right in general, unless we're talking about perlin noise or something like that, but those types of brushes are special purpose.
Keep in mind I don't want to restrict this to your usual TA-styled maps. I'm making this for Spring in general so basically anything goes. Further, Spring has always had a lot of weird, unrealistic maps and imo that's OK.
Fractals can be used for many purposes, even diffuse, but certain for other effects such as Lighten/Darken and similar.
I've added a library I found previously, feel free to revise it.
Example of what could be done with fractals:
screen00005.png
(4.22 MiB) Not downloaded yet
This is not to say that abstract/unrealistic stuff should be in larger amount than your natural textures though...
aeonios wrote:I'll probably start adding height brushes and such soon, once I get finished tying up loose ends with some other things I've got going.
If you mean the height brushes for the heightmap editing, then don't! Heightmaps are edited using a completely different system in Spring. They aren't modified as images at all. It would involve modifying the engine-provided heightmap texture through GLSL and then converting that modified texture back into Lua tables and Spring.AdjustHeightMap calls.
It's a lot of code and twice slower (both GPU, CPU as well as the data sending).

Texture brushes would be much more appreciated!
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Feature requests

Post by gajop »

PS: Here's some additional textures I haven't added to github.
See if any of them can be used.
aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Feature requests

Post by aeonios »

gajop wrote:Keep in mind I don't want to restrict this to your usual TA-styled maps. I'm making this for Spring in general so basically anything goes. Further, Spring has always had a lot of weird, unrealistic maps and imo that's OK.
Fractals can be used for many purposes, even diffuse, but certain for other effects such as Lighten/Darken and similar.
I've added a library I found previously, feel free to revise it.
Example of what could be done with fractals:
screen00005.png
Ow my eyes. :P Psychadelic maps might be cool, but that requires figuring out how to make them look good first. Anything goes works for me, but it'll take time before I get far enough to mess with crazy stuff like that.
gajop wrote:If you mean the height brushes for the heightmap editing, then don't! Heightmaps are edited using a completely different system in Spring. They aren't modified as images at all. It would involve modifying the engine-provided heightmap texture through GLSL and then converting that modified texture back into Lua tables and Spring.AdjustHeightMap calls.
It's a lot of code and twice slower (both GPU, CPU as well as the data sending).
That's kind of a problem. Blender, SME, unity editor and quite a few others allow you to edit height/displacement using shaped intensity brushes, and it's necessary to achieve practically any sort of effect aside from flat cliffs or rounded hills. Of course, I have no idea how that's actually implemented, but I assume that it can be done reasonably efficiently. On the other hand within spring itself it might be more complicated but I don't really know how all that works either.

EDIT: I downloaded your texture pack, I'll take a look at them later and see what you've got.
aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Feature requests

Post by aeonios »

Ok, I think I understand the basic problem here, correct me if I'm wrong.

Basically, the way you're doing height currently is to directly modify the height mesh using spring's internal functions, then generate a height map from the mesh, which is more or less what blender does. Thus, if you wanted to edit the height map as a texture, you'd have to use some contrived and roundabout method in order for the result to show up properly on the mesh, or else you'd have to reload the entire height map and spring would have to recalculate pathing for the entire map every time you made a change to it. Clearly neither of those solutions is particularly practical.

What is much more likely however is that blender and SME interpret height brushes as vector fields used to manipulate the mesh, then generate the height map from the mesh basically the same as (I assume) you're doing. The limitations of that are that you can't use layers or alpha blending/seamless height textures. In practice that's not really a big deal, since krita works quite well for that if you know how to use it, and I think a better solution would just be to write up a tutorial on it.

For basic height editing though, shape/intensity brushes are a must-have, and could still work well even if it was only a little better than SME. The main problem with SME, besides complete lack of undo/redo, is that depending on the length of click you can get very different results with raise/lower. When you want consistent/well controlled scaling it's kind of a nightmare. Scened has an additional advantage over SME, which is that it can directly read height scaling information from mapinfo.lua in order to determine the min/max scaling for height brushes.

I guess, anyway. :P
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Feature requests

Post by gajop »

aeonios wrote:Ok, I think I understand the basic problem here, correct me if I'm wrong.

Basically, the way you're doing height currently is to directly modify the height mesh using spring's internal functions, then generate a height map from the mesh, which is more or less what blender does. Thus, if you wanted to edit the height map as a texture, you'd have to use some contrived and roundabout method in order for the result to show up properly on the mesh, or else you'd have to reload the entire height map and spring would have to recalculate pathing for the entire map every time you made a change to it. Clearly neither of those solutions is particularly practical.

What is much more likely however is that blender and SME interpret height brushes as vector fields used to manipulate the mesh, then generate the height map from the mesh basically the same as (I assume) you're doing. The limitations of that are that you can't use layers or alpha blending/seamless height textures. In practice that's not really a big deal, since krita works quite well for that if you know how to use it, and I think a better solution would just be to write up a tutorial on it.

For basic height editing though, shape/intensity brushes are a must-have, and could still work well even if it was only a little better than SME. The main problem with SME, besides complete lack of undo/redo, is that depending on the length of click you can get very different results with raise/lower. When you want consistent/well controlled scaling it's kind of a nightmare. Scened has an additional advantage over SME, which is that it can directly read height scaling information from mapinfo.lua in order to determine the min/max scaling for height brushes.

I guess, anyway. :P
I'll try to explain this a bit.
Basically, in Spring you have two types of maps you can modify:
1) Diffuse map that acts entirely as an OpenGL texture
2) Height, grass, metal and type maps which are read and modified through the Spring-provided API.

This means that for 1) I can use OpenGL shaders (GLSL) to render any arbitrary combination of textures that are loaded via OpenGL. So, I can load a number of image files as textures and then use them in the GLSL shaders how I want.
For 2) however, I can only use the Spring API to read and change values at certain positions in Lua, and I can't rely on other images as they're not (easily) accessible from Lua. The reason this distinction is made is probably because the diffuse map is used just to render Spring, and has no bearing on the simulation. The other maps: height, type and metal obviously have impact to the simulation and thus that data is synced. I'm not sure why grass editing is synced, but that's probably just a relic of the past.
To summarize: 1) is unsynced and handled through OpenGL while 2) is synced and handled through the Spring API. The distinction between synced and unsynced isn't that important for me though, since I'm already synchronizing all texture changes, but it does mean that changing 2) to be modified in an unsynced way (as OpenGL textures) would quite likely be difficult.

Now to make things more confusing, even though I said 2) is only available through the Spring API, it turns out that most of it is also available as textures. For example, the height map is identified with the name "$heightmap". This however is only usable for reading, and you can't do unsynced changes there (at least I predict it would cause undefined behavior).

The fact it can be read as OpenGL textures at least means I might be able to use it for two things:
a) As an additional input when I'm modifying the diffuse map (e.g. making the diffuse map depend on the height map). The most obvious example would be to have the diffuse map match the height map
b) For the purpose of changing the height map. I could first create a copy of the existing height map, render to it as if it was an OpenGL texture, then transfer that texture information back to Lua and modify the actual height map with the Spring API. This is the thing I mentioned before, but I'm worried it might be rather inefficient.

I hope this clarifies things a bit.

PS: If you just want to provide support for some *simple* height editing through shapes, it might be possible to do so through the Spring API without any use of OpenGL/GLSL (if I could just load it in Lua as treat it as a normal table). It's just probably not going to be as powerful or fast as editing the diffuse map. (That means you can feel free to add some images to the Github repo, and I'll see if I can use that somehow).
PPS: I invite any more knowledgeable people to correct me.
aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Feature requests

Post by aeonios »

Hmm, I think it should be good enough. I think I understand what you mean about that, which is an engine limitation but the workaround is basically the same. I guess that makes better sense though, since doing anything with textures in openGL is fast regardless of what the textures may represent.

I sorted through those textures you posted and added a few to the collection. I cleaned up a few things as well and committed it. I think my next project is going to be converting the 'greenery' textures into something that looks less bad. I also added a bunch of height brushes, although some of them may still need further editing.

I played around with detail textures a bit, but tbh I don't think it's all that useful. With any of the patterns except 'spacer' it just makes the textures look like they're covered in soot. Using brushes as an intensity mask would be useful, but that's a different feature altogether.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Feature requests

Post by gajop »

Cool. I've updated the repo to use it.
We'll see about the detail texture. They definitely have their use (otherwise wouldn't be included in so many engines), but the correct detail texture might need to be picked depending on the material being used.
It might make sense to also have some semi-transparent textures for painting over the existing terrain. You can see how that looks if you turn the "blend factor" to low and use existing textures with distinct features.
Height-brushes :) I'll see if there's a way to use that. Also, Spring might have too low heightmap size for some of the ones you included.
Btw, do you have any videos how such heightmap editing is done in Blender? All I've found is editing the entire heightmap, which is basically terrain generation and a different subject entirely.
aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Feature requests

Post by aeonios »

gajop wrote:Cool. I've updated the repo to use it.
We'll see about the detail texture. They definitely have their use (otherwise wouldn't be included in so many engines), but the correct detail texture might need to be picked depending on the material being used. It might make sense to also have some semi-transparent textures for painting over the existing terrain. You can see how that looks if you turn the "blend factor" to low and use existing textures with distinct features.
Doing that does look very cool for lots of things. I'm not sure that there's a reason to paint more than one diffuse texture at a time though, since you can get the same effect with layers and/or low opacity passes. You get more control when doing it manually, which is what I prefer although other people give me funny looks when I tell them that. :P
gajop wrote:Height-brushes :) I'll see if there's a way to use that. Also, Spring might have too low heightmap size for some of the ones you included.
That depends on scaling, which is important. I don't think any of them are too small though, I got microdunes to work quite well on sea of dunes and they could have even been a bit smaller than that (brush size 70, went as low as like 40 or 50 iirc), except they looked better at the size they ended up. There are limits, but you'd probably be surprised what you can do.
gajop wrote:Btw, do you have any videos how such heightmap editing is done in Blender? All I've found is editing the entire heightmap, which is basically terrain generation and a different subject entirely.
Well, there are several different ways you could do that. One would be something like this, which is equivalent to subdivision surfaces in blender. You can also go into sculpt mode and set locks on the x and y axes, then use height brushes the same way we're doing here. Both methods require rendering to produce the final height map, and the first method distorts the grid which may or may not make it difficult to render to height.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Feature requests

Post by gajop »

aeonios wrote: Doing that does look very cool for lots of things. I'm not sure that there's a reason to paint more than one diffuse texture at a time though, since you can get the same effect with layers and/or low opacity passes. You get more control when doing it manually, which is what I prefer although other people give me funny looks when I tell them that. :P
Oh, detail and "semi-transparent" textures are unrelated.
Not sure about doing too much stuff manually. I like what enetheru's doing with tiles, and that's definitely the future for rapid map creating. I'd like to try combining height and texture map modifications or those sort of things. Will definitely combine diffuse, specular and normal once I figure out how to edit materials.
aeonios wrote: That depends on scaling, which is important. I don't think any of them are too small though, I got microdunes to work quite well on sea of dunes and they could have even been a bit smaller than that (brush size 70, went as low as like 40 or 50 iirc), except they looked better at the size they ended up. There are limits, but you'd probably be surprised what you can do.
I meant that they're too highly detailed (don't expect to be able to render that in Spring). 256x256 is the realistic maximum atm, while I wouldn't bother keeping them larger than 512x512.
aeonios wrote:this
I don't think that video had anything to do with what I'm doing right now :P

Anyway, I've added stuff, go play.
aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Feature requests

Post by aeonios »

gajop wrote:Oh, detail and "semi-transparent" textures are unrelated.
Not sure about doing too much stuff manually. I like what enetheru's doing with tiles, and that's definitely the future for rapid map creating. I'd like to try combining height and texture map modifications or those sort of things. Will definitely combine diffuse, specular and normal once I figure out how to edit materials.
Hmm, I checked over your (long list of) recent commits, and I see that some fixes for the detail tex were included so I'm probably just seeing the wrong thing. I pulled the new version but got some errors and the ui crashed again.

infolog: http://pastebin.com/VzNfkc5d

Also, the dependency for scened-resources doesn't seem to work properly in git (gives connection errors, seems to be pointing to the wrong place) when pulled with scened-core using git clone --recursive.

As for 'rapid map creation' and all of that, I dunno. I think art should still be a major option, if not the first choice, although map generation and combined techniques could be cool as well. After looking over some other interesting maps, I've concluded that my skills with making diffuse textures aren't good enough compared to what some other people have done. I think I need to consult beherith and see just how some of this stuff is done, like the cliffs/rocks on aberdeen. Or everything else on aberdeen, for that matter. I'm not sure if tiles would be compatible with something like that, either, but I dunno what enetheru is actually planning with all that stuff.

Either way, I think I should educate myself further in order to figure out what kinds of tools are actually needed in order to get awesome looking maps, and hopefully improve the texture collection by a lot. It seems I've still got a long way to go with all that.
gajop wrote:I meant that they're too highly detailed (don't expect to be able to render that in Spring). 256x256 is the realistic maximum atm, while I wouldn't bother keeping them larger than 512x512.
Ah it is true that some of them are bigger than the entire heightmap resolution for some maps. I think it's still better to have to scale down than to have to scale up, but I'll experiment with that and see.
gajop wrote:I don't think that video had anything to do with what I'm doing right now :P

Anyway, I've added stuff, go play.
Perhaps not, I'm never sure what kind of crazy stuff you're up to at any given time though. :P Anyway, gogo fixes. I'm excited to see what all has been added and improved.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Feature requests

Post by gajop »

Odd errors. Probably an issue with incorrect submodule links, but that should be fixed. You can try again now.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Feature requests

Post by FLOZi »

iirc, and it was a few years ago now, Aberdeen was made with the WorldInConflict map editor.
aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Feature requests

Post by aeonios »

gajop wrote:Odd errors. Probably an issue with incorrect submodule links, but that should be fixed. You can try again now.
Working again.

Terrain shape brushes don't work yet, but I figure you probably knew that. :P The interface for that seems about right, but the scale factor seems a little nonsensical. Elmos would be best.

I've also noticed that the way you implemented blend factor for textures is kind of odd. In SME or blender, if you paint over the same spot with the same texture at a low blend strength the opacity gradually increases until it maxes out. Your 'blend factor' is more like painting the texture to a separate layer with the layer opacity set to the blend factor. If you paint over the same spot it just achieves a uniform opacity, which is really useful and cool in its own right but not exactly normal behavior. That's especially bad for modes like add, where continuing to paint normally should continue to increase the brightness of the 'glow' effect. A lot of those fractals look amazing in add mode, btw.

I think you might be right about sorting out the modes that aren't useful, it seems like a few definitely wouldn't be, or at least would require special textures to do anything interesting. Colorize mode also doesn't work the way I'd hoped. I think your implementation is valid, but a more useful version would only set the hue without affecting brightness (which is what krita's color mode does). Detail textures still just look like soot to me. :P I think we may be missing something about how that's used in other editors, or maybe that's what splat details are used for in spring, idk.
FLOZi wrote:iirc, and it was a few years ago now, Aberdeen was made with the WorldInConflict map editor.
Hmm.. dunno, I haven't seen the guy who made it around anymore, I'll have to check the maps forum and see if I can dig anything up.

EDIT: you're right it was WIC. I'll have to look into that.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Feature requests

Post by gajop »

aeonios wrote:Terrain shape brushes don't work yet, but I figure you probably knew that. :P
It should work.. Notice the "Add Shape" button? Or try pressing "5" when in any heightmap editing mode.
GUI needs cleaning up there, but I want to separate the "normal" add/level/smooth from the shape add one (which seems more difficult to underestand).
If it still doesn't work and you are indeed on the latest version, submit an infolog and I'll try to debug it.
Just note one thing, you might have packets being dropped if you have the default springsettings.
You should have things like this in your config:
LinkIncomingMaxPacketRate = 64000
LinkIncomingMaxWaitingPackets = 512000
LinkIncomingPeakBandwidth = 32768000
LinkIncomingSustainedBandwidth = 2048000
LinkOutgoingBandwidth = 65536000
MaximumTransmissionUnit = 140000
Numbers are arbitrarily large. The MTU probably doesn't need to be changed, but I couldn't be bothered to figure what does so I made everything network related large :p
You should also run this on your own machine for now and avoid using hosts. The networking is still unoptimized.
aeonios wrote: The interface for that seems about right, but the scale factor seems a little nonsensical. Elmos would be best.
Hmm OK, but let's leave that for later when it's time to fix the UI. It's not like the user is ever informed about the map size, so those numbers are asbtract for now!
aeonios wrote: I've also noticed that the way you implemented blend factor for textures is kind of odd. In SME or blender, if you paint over the same spot with the same texture at a low blend strength the opacity gradually increases until it maxes out.
OK, changed the blend factor to work more like the way you suggested. It really does make Add a lot more useful.
aeonios wrote: Your 'blend factor' is more like painting the texture to a separate layer with the layer opacity set to the blend factor. If you paint over the same spot it just achieves a uniform opacity, which is really useful and cool in its own right but not exactly normal behavior.
Since I also really liked my old blend factor I added it as "feature factor" (in need of a better name maybe). It pretty much filters only "features" of the texture if at low value.
aeonios wrote: I think you might be right about sorting out the modes that aren't useful, it seems like a few definitely wouldn't be, or at least would require special textures to do anything interesting. Colorize mode also doesn't work the way I'd hoped. I think your implementation is valid, but a more useful version would only set the hue without affecting brightness (which is what krita's color mode does).
Could you make suggestion how the list should look like?
Also separate what you think is not usable.
I'll put the colorize change on the TODO list :p
aeonios wrote: Detail textures still just look like soot to me. :P I think we may be missing something about how that's used in other editors, or maybe that's what splat details are used for in spring, idk.
Spring uses both.
Detail: https://springrts.com/wiki/Mapdev:detail
and
Splat detail: https://springrts.com/wiki/Mapdev:splatdetail
The example images there are poor examples (!invoke enetheru), with "without splat" looking even better to me, but beherith's map example does look great: viewtopic.php?f=13&t=22564

I'm already using RGB(A) detail textures like in the splat example, but I don't have a "Distribution image", and I'm not sure how to generate it. That said, using RGBA detial textures until splatting is done is probably a bad idea, as it just multiplies the colors. Stick with greyscale.

PS: Also increased the maximum texture size as performance was OK (for me).
PSS: Now also saves old height/texture window states.
FLOZi wrote:iirc, and it was a few years ago now, Aberdeen was made with the WorldInConflict map editor.
There, more stuff for reference =)
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Feature requests

Post by FLOZi »

NB: WICed is free but requires WIC to be installed (which ofc isn't)
aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Feature requests

Post by aeonios »

gajop wrote:It should work.. Notice the "Add Shape" button? Or try pressing "5" when in any heightmap editing mode.
GUI needs cleaning up there, but I want to separate the "normal" add/level/smooth from the shape add one (which seems more difficult to underestand).
If it still doesn't work and you are indeed on the latest version, submit an infolog and I'll try to debug it.
Just note one thing, you might have packets being dropped if you have the default springsettings.
You should have things like this in your config:
LinkIncomingMaxPacketRate = 64000
LinkIncomingMaxWaitingPackets = 512000
LinkIncomingPeakBandwidth = 32768000
LinkIncomingSustainedBandwidth = 2048000
LinkOutgoingBandwidth = 65536000
MaximumTransmissionUnit = 140000

Numbers are arbitrarily large. The MTU probably doesn't need to be changed, but I couldn't be bothered to figure what does so I made everything network related large :p
You should also run this on your own machine for now and avoid using hosts. The networking is still unoptimized.
I've only been running it in single player since I saw the warnings about that, and since the git version wouldn't work with autohosts anyway.

I did find the 'shape brush' mode, which gives me a square brush that does basically nothing, although it hangs for a minute at first like textures do when loading. I checked out the infolog and found a bunch of related errors.

infolog: http://pastebin.com/04M1mUGN
gajop wrote:Hmm OK, but let's leave that for later when it's time to fix the UI. It's not like the user is ever informed about the map size, so those numbers are asbtract for now!
No, but you do have to set those in mapinfo.lua before you do any editing. Elmo scaling would be most important for set mode though, as a reminder of that. :P
gajop wrote:OK, changed the blend factor to work more like the way you suggested. It really does make Add a lot more useful.
I'll be sure to test that with the next round of fixes. That should help a lot with usability.
gajop wrote:Since I also really liked my old blend factor I added it as "feature factor" (in need of a better name maybe). It pretty much filters only "features" of the texture if at low value.
I was thinking it should be an extra option (ie fixed strength vs accumulate) tagged onto the blend factor, since it could be/was used with any mode. :P
gajop wrote:Could you make suggestion how the list should look like?
Also separate what you think is not usable.
I think what I'm gonna do is look up what those modes are supposed to be used for in the first place, and then figure out which ones don't apply to map editing. I'll post when I get around to that.
gajop wrote:I'll put the colorize change on the TODO list :p
Awesome.
gajop wrote:Spring uses both.
Detail: https://springrts.com/wiki/Mapdev:detail
and
Splat detail: https://springrts.com/wiki/Mapdev:splatdetail
The example images there are poor examples (!invoke enetheru), with "without splat" looking even better to me, but beherith's map example does look great: viewtopic.php?f=13&t=22564

I'm already using RGB(A) detail textures like in the splat example, but I don't have a "Distribution image", and I'm not sure how to generate it. That said, using RGBA detial textures until splatting is done is probably a bad idea, as it just multiplies the colors. Stick with greyscale.
Yeah, I need to figure out the difference and what those are for. I would guess splat maps are probably 8-bit type maps, but I dunno what resolution.
gajop wrote:PS: Also increased the maximum texture size as performance was OK (for me).
PSS: Now also saves old height/texture window states.
I noticed you also fixed the hotkeys. :P
gajop wrote:There, more stuff for reference =)
Apparently it can smoothly wrap a cliff texture around a curved surface. I dunno if that's just brush rotation or what, but I think it'd pay to find out. It seems like everyone here is using WM though, which I'm looking into now.

EDIT: ok now this post is sorted out lol.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Feature requests

Post by gajop »

aeonios wrote:I've only been running it in single player since I saw the warnings about that, and since the git version wouldn't work with autohosts anyway.

I did find the 'shape brush' mode, which gives me a square brush that does basically nothing, although it hangs for a minute at first like textures do when loading. I checked out the infolog and found a bunch of related errors.

infolog: http://pastebin.com/04M1mUGN
There is nothing for me to fix, and I'm not going to spend any time optimizing the networking for now. (Shapes are loaded through network, locally).
Refer to this:
gajop wrote: You should have things like this in your config:
LinkIncomingMaxPacketRate = 64000
LinkIncomingMaxWaitingPackets = 512000
LinkIncomingPeakBandwidth = 32768000
LinkIncomingSustainedBandwidth = 2048000
LinkOutgoingBandwidth = 65536000
MaximumTransmissionUnit = 140000
aeonios wrote: I was thinking it should be an extra option (ie fixed strength vs accumulate) tagged onto the blend factor, since it could be/was used with any mode. :P
They work differently and can be used in combination, thus separate options.
aeonios wrote:Yeah, I need to figure out the difference and what those are for. I would guess splat maps are probably 8-bit type maps, but I dunno what resolution.
They look like they have color. It probably gets multiplied by the detail tex to create a greyscale or map-wide detail tex. Haven't investigated yet.
Post Reply

Return to “SpringBoard”