Spring Map Edit Revisted

[MasterBel2]

Double-clicking the file doesn't work. I'm launching with the sh command, and I still get these two errors:

Code: Select all

: command not foundline 2: 
: command not foundline 5: 

Apart from that, it waits, as if processing something.

This is what I get when I force quit the program:

Details.txt

(1.3 MiB) Downloaded 11 times

[aeonios]

The two normal errors are just from the newlines in the script file, which doesn't actually break anything. The output of that ridiculous dump just says "SWT is broken". The only thing I can suggest is to try downgrading SWT until you find a version that works. SME should really only take a few seconds to load, and it has a splash screen kind of thing that pops up first, just FYI.

[MasterBel2]

Code: Select all

2016-08-12 15:43:57.055 java[12138:62008] *** WARNING: Method userSpaceScaleFactor in class NSWindow is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead. 
BrushManager added Pattern: circle
BrushManager added Pattern: circle_double
BrushManager added Pattern: circle_small
BrushManager added Pattern: ellipse
BrushManager added Pattern: ellipse_cross
BrushManager added Pattern: noise
BrushManager added Pattern: noise2
BrushManager added Pattern: noise2_smooth
BrushManager added Pattern: square
BrushManager added Texture: beach
BrushManager added Texture: beach2
BrushManager added Texture: dirt1
BrushManager added Texture: dirt2
BrushManager added Texture: drygrass
BrushManager added Texture: grass
BrushManager added Texture: grass2
BrushManager added Texture: grass3
BrushManager added Texture: grass4
BrushManager added Texture: grass5
BrushManager added Texture: grass6
BrushManager added Texture: ice
BrushManager added Texture: metalpatch
BrushManager added Texture: mud1
BrushManager added Texture: mud2
BrushManager added Texture: road1
BrushManager added Texture: sandstone
BrushManager added Texture: sandstone2
BrushManager added Texture: stone
BrushManager added Texture: stone2
BrushManager added Texture: stone3
BrushManager added Texture: ttd
PrefabManager added Prefab: Ramp Down SW
BrushManager added PrefabHeightmap: Ramp Down SW_hm
BrushManager added PrefabTexturemap: Ramp Down SW_tm
 Done scaling Texture from 256x256 to 256x256: 51 ms
 Done scaling Texture from 256x256 to 256x256: 0 ms
 Done scaling Texture from 512x512 to 512x512: 38 ms
 Done scaling Texture from 512x512 to 512x512: 1 ms
FeatureManager: added Feature: cluster1
FeatureManager: added Feature: cluster1_dead
FeatureManager: added Feature: corecom1
FeatureManager: added Feature: geovent
FeatureManager: added Feature: rock1
FeatureManager: added Feature: mc2chemicalplant
FeatureManager: added Feature: S44tree_01a
FeatureManager: added Feature: S44tree_01b
FeatureManager: added Feature: S44tree_01c
FeatureManager: added Feature: S44tree_02a
FeatureManager: added Feature: S44tree_sprucea
FeatureManager: added Feature: S44tree_spruceb
FeatureManager: added Feature: smothdist
FeatureManager: added Feature: Tyranid1
FeatureManager: added Feature: Tyranid2
FeatureManager: added Feature: Tyranid3
FeatureManager: added Feature: TyranidC
Done blanking texture ( 19 ms )
Done blanking featureMap ( 0 ms )
OpenGL version: 2.1 INTEL-10.18.43 -> (ok)
Exception in thread "main" javax.media.opengl.GLException: OpenGL context not current
	at com.sun.opengl.impl.macosx.MacOSXGLContext.setSwapInterval(MacOSXGLContext.java:317)
	at com.sun.opengl.impl.GLImpl.setSwapInterval(GLImpl.java:30518)
	at frontend.render.MapRenderer.init(MapRenderer.java:1856)
	at frontend.gui.SpringMapEditGUI.<init>(SpringMapEditGUI.java:295)
	at application.SpringMapEditApplication.main(SpringMapEditApplication.java:61)

I think it's starting to work. Almost there. So close I can taste it. Right down the bottom though it hits an exception.

Achieved using SWT 3.6.2.

[aeonios]

Version noted. On the other hand GLContexts are evil.

[MasterBel2]

So… what should I be looking to do now to get it over the hump and working?

[aeonios]

Basically all I can tell you is that it's either a conflict between SWT and JOGL or a conflict between SWT/JOGL and cocoa. Unfortunately I have no idea what SWT/JOGL versions codeman used, but that'd be the basic starting point.

[MasterBel2]

SWT 4.5 and JOGL 1.1.1 is what it says in the readme

I know I'm using an earlier version of SWT, and I know they're both supposed to support Cocoa. I don't know which version of JOGL is packaged with SME though. I also wouldn't know which specific files from JOGL 1.1.1 I'd need to get, or which exact version of 1.1.1 I'd need to Download. Probably the mac one, though the start script would probably have to be editted.

[aeonios]

After looking at all the evidence it seems like JOGL is the most likely culprit. JOGL 1.1.1 is ancient to the point where I'm surprised that it supported OSX64 at all, and it most definitely doesn't support any of the recent changes to the OS. Unfortunately upgrading JOGL is not exactly trivial, so it'll be some time before that gets done. I'll have to post a new version for you when I get around to it.

[MasterBel2]

Cool! looking forward to being able to make some maps!

[aeonios]

Bad news. I got it ported to JOGL 2.x but the JVM crashes after a few seconds when running JOGL 2.x. I have no idea why, possibly just because JOGL 2.x hates fixed-function openGL, but there doesn't seem to be anything I can do about it at least for the near future. Eventually I plan on switching to shaders, which may or may not help, but that's not particularly soon. I could alternatively switch to lwjgl, which is more actively maintained, but that'd be an even bigger pain and again, not any time soon.

[MasterBel2]

I can wait. I think I'm patient enough.

[aeonios]

So, I finally got it cleaned up to the point where I feel like making a release. I'm calling this release 1.4.0 in line with the 1.3.x released here previously.

This version moves to a single-window interface with all the brush selection windows also combined into the brush control panel. The interface has been cleaned up considerably and lots of bugs were fixed such that everything should now work as expected.

Camera controls have also been dramatically improved. Never again will you have to hit "L" to switch between zoom and pan; arrow keys always pan, the mouse wheel zooms in and out (alternatively page up/page down if you happen to be mouse-impaired) and you can reset the camera to the (now much more sensible) default position/orientation by pressing TAB. Mouselook using the middle mouse button also works much more intuitively than it used to.

Settings have also been cleaned up, and rendering has been improved a little as well.

Other things probably worth mentioning:
-height mode now has a stamp mode, which is just like raise/lower except you get exact heights per click.
-all texture brushmodes now respect texture alpha.
-texture paint now has a multiply mode
-texture stamp mode now works as you would expect it to. (ie it centers the texture under the brush and does not tile)
-When rotating the brush in prefab mode, it no longer rotates the texture and terrain in opposite directions.
-Smooth height no longer bugs out near map edges or when applied to extreme slopes, and works more intuitively in general.
-The map max height setting and water level setting are now in elmos.
-The brush strength slider now scales depending on the currently selected brush. Most height brushes now scale with map maxheight (ie the number is in elmos), texture brushes use a scale of 1-100, and metal and terrain type modes use a scale of 1-255 so you get more exact numbers (which are absolutely necessary for the typemap).

you can get it on github or springfiles.

[gajop]

This is the first SME release I've tested since ages. I don't think I tried anything in this thread even.
Issues:
- Script start_linux_x64.sh should have a +x mode (execute), and with unix file endings, otherwise we get errors about the wrong interpreter.
- Middle mouse camera controls shouldn't instantly move you so drastically when you click.
- Mouse pointer doesn't correctly reflect on the terrain position (there's quite an offset between what I'm pointing on and where it ends on the terrain).
- I suggest using sliders and/or numbers for rotation. Hard to tell what's going on if nothing is displayed.
- Draw the current height brush texture with its rotation on the map. Like http://i.imgur.com/4EAHBGz.jpg http://i.imgur.com/ThTh1xz.jpg.
- There are weird rendering issues. You're culling some triangles you shouldn't have.
- What's the yellow thing rotating above? The sun? Why does it need to rotate? I guess I find the way terrain flashes a bit distracting.
- I think I'd prefer a simpler interface, with just Add/Remove (incremental/decremental) and Set (goal-height) controls. A set with a small strength is also pretty useful (took that idea from Unity), and it allows you to create these plateaus easily (http://i.imgur.com/Ljd1eci.jpg). I guess I don't think the normal brushes work well with just stamp.

In general though it seems straight forward, although I'm probably not the best person to test intuitiveness on. Hopefully you won't take it as offense, but I think it's quite behind what Scened can offer, so I'm curious to ask why you've decided to work on this? I don't mind of course, as it doesn't hurt the ecosystem to have multiple competing solutions (good ideas from different projects can be captured). What are in your opinion the pros of SME in comparison to Scened?

[prandipadaro]

- Script start_linux_x64.sh should have a +x mode (execute), and with unix file endings, otherwise we get errors about the wrong interpreter.

i try to test this release but i'm unable to do it under linux
i get the execute permission and try to launch it with:

Code: Select all

./start_linux_x64.sh

go i get the interpreter error

[gajop]

Code: Select all

./start_linux_x64.sh

go i get the interpreter error

As I said, you also need to make it have unix line endings.
I did it via vim, but I guess you could also use a tool like dos2unix.

[prandipadaro]

I did it via vim, but I guess you could also use a tool like dos2unix.

ah... now i understand, I did not know there were these differences!
any case i have solved with kate editor, thanks

[aeonios]

This is the first SME release I've tested since ages. I don't think I tried anything in this thread even.
Issues:
- Script start_linux_x64.sh should have a +x mode (execute), and with unix file endings, otherwise we get errors about the wrong interpreter.

Derp, broke that. I'm not on linux so I can't chmod, someone else would have to make the releases for that.

- Middle mouse camera controls shouldn't instantly move you so drastically when you click.

That was something I inherited from the forum version. I'll add that to the list of things to fix.

- Mouse pointer doesn't correctly reflect on the terrain position (there's quite an offset between what I'm pointing on and where it ends on the terrain).

That could probably be improved. The current screenray algorithm doesn't account for the perspective warp of the camera, which is why. AFAIK it's always been like that though.

- I suggest using sliders and/or numbers for rotation. Hard to tell what's going on if nothing is displayed.

I was thinking more along the lines of an image of the text "UP" so that you can see which direction it's facing easily. SME doesn't support non-90-degree rotations so a slider doesn't make much sense.

- Draw the current height brush texture with its rotation on the map. Like http://i.imgur.com/4EAHBGz.jpg http://i.imgur.com/ThTh1xz.jpg.

There's a hidden option for that but it's broken so it isn't enabled. I have no idea why it doesn't work.

- There are weird rendering issues. You're culling some triangles you shouldn't have.

I can't tell what I'm looking at there. What's all that weird jaggy stuff in the background?

- What's the yellow thing rotating above? The sun? Why does it need to rotate? I guess I find the way terrain flashes a bit distracting.

There's an option to turn off sun rotation, but it can be hard to see the terrain relief without it. Yes, that stupid yellow sphere is the 'sun'. It's always been like that. Eventually I plan to use a real skybox rendering algorithm (like this) and to add proper controls for sun position, but it wasn't at the top of my list of things to do.

- I think I'd prefer a simpler interface, with just Add/Remove (incremental/decremental) and Set (goal-height) controls. A set with a small strength is also pretty useful (took that idea from Unity), and it allows you to create these plateaus easily (http://i.imgur.com/Ljd1eci.jpg). I guess I don't think the normal brushes work well with just stamp.

I actually found a bunch of uses for stamp which I'll probably demonstrate soon. Smooth is also pretty useful/necessary. (I thought scened had smooth?) I may even bring back the erosion brush since I've thought of a possible use for it. (making individual buttes)

In general though it seems straight forward, although I'm probably not the best person to test intuitiveness on. Hopefully you won't take it as offense, but I think it's quite behind what Scened can offer, so I'm curious to ask why you've decided to work on this? I don't mind of course, as it doesn't hurt the ecosystem to have multiple competing solutions (good ideas from different projects can be captured). What are in your opinion the pros of SME in comparison to Scened?

Well, SME is written in java, which is much nicer to use than lua. It also allows a nicer interface than chili since I can take my pick of widget toolkits that have proper layout control (and a free HSV color picker). Compared to spring it doesn't have any pathing to update, so terrain editing can be arbitrary without performing too badly. I eventually plan to add support for terrain/texture generation, so that's kind of important. I can also play with the rendering much more easily than I can with spring's, which is something I plan on doing sooner or later.

[gajop]

- There are weird rendering issues. You're culling some triangles you shouldn't have.

I can't tell what I'm looking at there. What's all that weird jaggy stuff in the background?

Basically there's a mountain that isn't rendered when viewed from this side. The wrong triangles are being culled causing the weird things to happen.

I actually found a bunch of uses for stamp which I'll probably demonstrate soon.

I guess I don't see why you'd want it if you could do the same with Set & a fixed height, but looking forward to see what you do with it.

Smooth is also pretty useful/necessary. (I thought scened had smooth?) I may even bring back the erosion brush since I've thought of a possible use for it. (making individual buttes)

Yes, both smooth and erosion are also useful, as are a number of more complicated heightmap transformations such as ramps.

Well, SME is written in java, which is much nicer to use than lua. It also allows a nicer interface than chili since I can take my pick of widget toolkits that have proper layout control (and a free HSV color picker). Compared to spring it doesn't have any pathing to update, so terrain editing can be arbitrary without performing too badly. I eventually plan to add support for terrain/texture generation, so that's kind of important. I can also play with the rendering much more easily than I can with spring's, which is something I plan on doing sooner or later.

I don't mind Chili so much anymore, it's gone quite far and will only improve further with Chobby and Scened as very heavy UI programs. I've got a HSV picker too, thanks to smoth.
I think pathing should be trivial to disable, I'm not sure yet what's causing the biggest performance hit wrt heightmap updates, but I bet that can be improved on drastically.
I think it's good that Scened relies on Spring rendering as I get a very obvious WYSIWYG. You mentioned SSAO, and I'd rather that be first implemented in Spring in general, PRs welcome

I guess I like the idea that my Scened needs also make Spring & related libs better in general. Having better map heightmap and texture generation would be pretty useful if we ever wanted to make procedurally generated games, like roguelikes. Better rendering is also obviously good. I don't want to crush your ideas and work (I fully support it), but if those are your main concerns, I can sleep better knowing the choice I made with Scened is solid.

[aeonios]

Basically there's a mountain that isn't rendered when viewed from this side. The wrong triangles are being culled causing the weird things to happen.

That seems to be a JOGL issue, and probably linux-specific. JOGL is a piece of crap and I'm getting rid of it one way or the other.

I guess I don't see why you'd want it if you could do the same with Set & a fixed height, but looking forward to see what you do with it.

There are things you can do with stamp that you can't do with set. Like add to existing terrain.

I think it's good that Scened relies on Spring rendering as I get a very obvious WYSIWYG. You mentioned SSAO, and I'd rather that be first implemented in Spring in general, PRs welcome

SSAO actually wasn't one of the things I planned on implementing. WRT to spring's rendering imo it should be burned in a fire along with the entire contorted failure of a materials system (however many different ones it uses). Also, I might, but only if/when I ever feel like dealing with the ridiculous compile procedure on windows.

Having better map heightmap and texture generation would be pretty useful if we ever wanted to make procedurally generated games, like roguelikes.

I don't see that as being very practical. I guess if you only needed non-realtime level generation it could be doable, but in that case you could just hack around it with lua.

[aeonios]

After fixing the bugs that came up and running some tests, I've determined that the new elmo-denominated SME is in fact compatible with old non-mapinfo.lua formats. Apparently the old format used the exact same minheight-maxheight-waterplane-is-zero that mapinfo.lua does, also in elmos, and it was just SME that used screwy height units.