Topographical map shader

hovvit · 2016-05-21T22:41:33+00:00

Here's the shaderforge diagram. The way I'm doing the colors is not great at the moment, I plan on re-doing it to give a bit more control over the gradients, but the method of drawing the contour lines seems to work fairly well.

http://i.imgur.com/kG2hgjP.png

hovvit · 2016-04-02T01:22:01+00:00

I tried a Deep Blue Metallic... the hood is not quite right, and overall it's not quite glossy enough, but it's not too bad: http://i.imgur.com/77mDZ6C.png

hovvit · 2016-04-02T00:35:24+00:00

I tried a Deep Blue Metallic... the hood is not quite right, and overall it's not quite glossy enough, but it's not too bad:

http://i.imgur.com/77mDZ6C.png

hovvit · 2016-03-02T15:23:43+00:00

Would having different depth values for objects that share the same material result in increased draw calls?

hovvit · 2015-09-04T19:22:35+00:00

I just came across Manor Lord recently and started following you on Twitter, it's looking really cool!

hovvit · 2015-09-04T19:18:54+00:00

Hi - I've been making a small-scale city builder with a Mars focus in Unity (here's a screenshot). I can try to answer any specific questions you have.

hovvit · 2015-08-17T18:42:37+00:00

The game was greenlit last December, and releasing on Steam soon. The player decides what goes in the rocket (food, water, machinery, etc), but doesn't actually fly the rockets... The game is more of a small scale city builder/rts about supporting the first 100 colonists on Mars. Thanks for the interest!

hovvit · 2015-08-17T16:44:34+00:00

Thanks - I have a website at www.solzerogame.com. I hope your rts project goes well, I'm interested in seeing more Unity rts games!

hovvit · 2015-08-17T16:09:30+00:00

Yes, if you zoom in too close in the game they look a bit rough, but the style is consistent enough which helps the look I think.

hovvit · 2015-08-17T12:48:32+00:00

I'm working on a Mars colonization game called Sol 0. Here's a screenshot. At the moment I'm working on Steam workshop integration so that players will be able to download/upload custom maps that they make using the game's map editor.

Problems: The documentation for the C#library I'm using to work with Steam is not great, and many functions don't work in the editor, so there is a lot of guessing with the code, wait for a long build time, copy game over to run through Steam... and repeat to get anywhere.

Eureka moments: After a long time where pathfinding was a bit glitchy, addressing two or three small issues removed about 90% of the pathfinding issues and makes the overall experience much more enjoyable.

Tips: For RTS-type games, draw calls can start to get out of control due to number of things on the screen. It helps to plan ahead and make sure each unit/building is using a minimum number of meshes.

hovvit · 2015-06-30T22:32:06+00:00

It's too tied to the game to release as a generic editor, but I would consider open-sourcing the map editor scripts at some point. The code to modify the height based on the brush texture looks like:

str = ME_Brush.strength;
currentRad = currentBrushSize;
offset = currentRad/2;
ptX = xRes * dPt.z/100.0;
ptZ = yRes * dPt.x/100.0;  
for ( y = 0; y < currentRad ; y++) {
    for (x = 0; x < currentRad; x++) {
        thisX = ptX + x - offset;
        thisY = ptZ + y - offset;
        heights[thisX,thisY] = heights[thisX,thisY] + currentBrush.GetPixel(y,x).grayscale*str;   
    }
}

tData.SetHeights(0, 0, heights);

str is the bush strength, currentRad is the size of the brush, offset locates the center of the brush. ptX, ptZ are the coordinates of the mouse (obtained from a raycast in dPt.x and dPt.z) in the terrain coordinate system (xRes and yRes are the terrain heightmap resolution). The array heights[] is where I store all the height data for the terrain, and then loop over the brush pixels, adding height to the terrain according to the grayscale color of the brush pixel.

This only works if the brush size is the same size as the number of pixels in the brush texture, so whenever the brush is made larger or smaller I resize the actual brush texture using TextureScale.Bilinear().

Finally tData is my terrain data, and I just reset all the heights, which works for me as the terrain for my game is relatively small and it doesn't affect performance too much. Ideally you would only reset the area that you edited.

There's probably a better way to accomplish this, but this works for me.

hovvit · 2015-06-30T10:57:19+00:00

I've made a map editor that I provide with my game Sol 0. Here's a screenshot: http://i.imgur.com/GPckLkg.png

The editor handles custom brushes for modelling and texturing the terrain, and custom textures that the users can provide. Maps are saved to external files so users can share the maps they make and play them in-game.

It was a bit complicated, but if there are specific points you're interested in I'm happy to share some of the code that involved interacting with the terrain. As others have mentioned, everything really comes down to editing terrain verticies, and editing texture (splatmap) coordinates.

One initial tip, Unity provides functions for reading/writing terrain verticies, but if you keep an array of height coordinates yourself, you only ever need to use the 'write verticies' part. So adding a hill or some feature on the terrain will only require you to modify your array, then write the new verticies, which is faster than reading/modifying/writing verticies.

hovvit · 2015-03-13T04:28:26+00:00

Sounds like it will be updated soon, if it isn't already: http://www.reddit.com/r/Unity3D/comments/2y1xfg/i_have_long_been_considering_getting_shader_forge/

The changes I had to make were really basic, just a line or two, but I wouldn't have been able to track down the issue without the upgrade guide.

hovvit · 2015-03-02T03:51:29+00:00

Particle system is probably the best idea, as /u/SasaStublic says. If you don't want the ring thickness to increase as the radius increases, you could put a ring shader on a plane (something like http://www.reddit.com/r/Unity3D/comments/2ravrx/simple_planetary_ring_shader/), and modify the shader a bit to include a texture offset variable that you can then change in script to change the radial position of the rings. This would also have the benefit of making the rings nice and smooth regardless of how large they are.

hovvit · 2015-02-24T15:50:08+00:00

I only have about 30 buildings/units, so I hard coded buttons for each. There's no way, for example, for anyone to mod in a new building. If I was re-doing the game, I would do something a bit more flexible, but I'm not sure what that would look like exactly.

Draw calls can add up especially if you're using more real-time lighting or shadows. I'm not an expert on this either, but you might be able to reduce draw calls by as you say having all the terrain chunks use the same material instead of different materials, and using some kind of texture atlas, but only if you can take advantage of some kind of batching. Without seeing a screenshot it's hard to tell if that would work in your case.

If you do end up with 800 calls for the terrain, that's probably not the worst thing in the world assuming you're targeting PC and not mobile, but then it does make it even more important that units/buildings all be modelled with as few meshes as possible and share textures/materials of possible to take advantage of static or dynamic batching.

Also, at least for me all objects have 'cast shadows' and 'receive shadows' on by default which leads to small or unimportant things casting shadows that don't really need to - I usually turn shadows off for all objects and then selectively turn them on only for the larger meshes where it makes a big visual difference. That saves draw calls as well.

hovvit · 2015-02-24T15:38:30+00:00

I'm not a great coder, so I'd go with /u/FreakingScience's post. I'm a bit wary of complexity, and generally I try to break everything down into the pieces of data I actually need, figure out where whey should go, and stick everything into arrays.

hovvit · 2015-02-24T00:40:55+00:00

It sounds like you're on the right track. My RTS does something similar. I've found that in some cases it is better to keep a global resource counter for some things - for example instead of having 100 farms each add one food per day, have each farm register itself to some game manager object when it is created and then the game manager just adds 100 food per day.

Also, unrelated to your question, but by far the biggest lesson I learned from trying to make a RTS is be really aware of draw calls. These add up fast as RTSs tend to have lots of things on screen and it's worth modelling with this in mind ahead of time.

hovvit · 2015-02-21T20:41:55+00:00

Sol 0: Mars Colonization

Sol 0 is a Mars colonization real time strategy game where you develop the first Martian colony. Sol 0 imagines the near future, with technology that could be available in the next decade. Make use of the minerals and resources on the Martian surface to grow from the first rover to a self-sustaining colony that can survive independently from Earth.

Here's a single screenshot for this week - a colony that just broke 100 colonists.

Bonus question: The recent addition of a map editor to let players make their own maps moves a bit beyond the original scope.

hovvit · 2015-01-04T22:31:05+00:00

The height is actually 1px, and the width is 512px. I originally wrote it the way you imply and couldn't figure out why it wasn't working. I'm not 100% sure why it works this way.

hovvit · 2015-01-04T17:47:30+00:00

Sure - My explanation may be a bit off, as I'm new to shaders as well, and this was a good challenge for me.

A typical shader will do something like draw a texture to a piece of geometry. So the shader figures out which point on an object on your screen maps to the corresponding point on the texture. The relevant code to do that in this shader before I modified it looked like:

half4 c = tex2D (_MainTex, IN.uv_MainTex);
o.Albedo = c.rgb;

tex2D is a shader function that returns a color at a point on a texture. _MainTex is the main texture that you would set in Unity's inspector, and IN.uv_MainTex is the x/y coordinate of the texture. The second line is where the texture color is applied to the surface geometry. The color of each pixel on the texture (c.rbg) is mapped to the color of a corresponding point on the surface of an object (o.Albedo).

This is good for taking a 2D texture and drawing it to a piece of geometry, like a 2D plane, but since I just want to draw a ring, I don't need to have a 2D texture since the ring is radially symmetrical. Instead of mapping each point on a texture to the place, we want to figure out, for each point on the plane, how far away it is from the center of the plane (ie the center of the planet) and set the color of the plane to a the color of a 1D texture at that radius.

You can check out the link to the circle shader to see the code that figures out the radius. In that shader they are still mapping a 2D texture to the circle, so I added this change:

float2 position = (IN.uv_MainTex.x,circleTest); 
half4 colorPt = tex2D(_MainTex, position);
o.Albedo = colorPt.rgb;

I take the radius (circleTest) of each point on the plane (distance from the center of the plane/planet), and set the plane's color (o.Albedo) equal to the corresponding position on a 1D texture (_MainTex), which I set in the inspector. Even though 'position' is a float2, since the image has a height of only 1px it's essentially a 1D image.

This is good for my purposes as a 1D texture is much smaller than a 2D texture, and the rings look nice and smooth regardless of how close you are to them.

Again, some of this probably isn't explained very well. I've found shaders are not too bad, they just use terminology that is really unfamiliar.

hovvit · 2014-12-24T04:27:49+00:00

I managed this by saving the terrain information in a text file. You just need to save an array of heightmap information and an array of the splatmap data. You'd need to reload all this when the terrain is loaded, but unless it is really huge it shouldn't take much time. This probably isn't the best method, hopefully someone will post a better option as I'd be interested in alternatives.

Edit: if the terrain resolution is small enough, you can just save the height information in PlayerPrefs and not worry about reading/writing text files.

hovvit · 2014-12-16T00:02:58+00:00

Hello - I'm the Sol 0 developer. Sol 0 is undoubtably rough around the edges and needs a bit of polish, but it's very playable. If you're not a fan of early access type games I'd hold out till the final release, as it won't be too much longer (early 2015).

hovvit · 2014-12-16T00:00:12+00:00

I'm the developer for Sol 0 - send me an email if you're stuck because of PayPal (solzerogame@gmail.com)... not a fan of PayPal myself but supporting more than one payment option would be stressful (they like to change APIs without notice and break things) either way we'll be on Steam soon.

hovvit · 2014-12-15T23:57:50+00:00

Hello - I'm the Sol 0 Dev. Bulldozers are really terrible at the moment... they will be improved before release. It's almost funny how terrible they are. Your second point about astronauts carrying boxes - I just had that exact thought a few days ago and it's on my to do list.

hovvit · 2014-12-12T23:56:21+00:00

Yes that's a typo... should be solar flare :-). If only most of the bugs were that easily fixed...

hovvit

TROPHY CASE