Dev Blog
Hi, this is the Stranded III development blog (see also Forum Thread, Comment Thread).
Entry 25 - New Job, FPS Display & Handling Terrain Trees - May 27, 2015
Oh.. this is funny. You should know that I connected the dev blog with my forum at www.UnrealSoftware.de. I simply did this to be able to use the forum for posting and editing dev blog entries. This way I don't have to write an extra interface for these tasks.
Well.. I just thought about writing a new entry - even though I don't have much to tell and even less to show - and then my (self-written uber awesome) forum software came up with this fancy message:
So the last dev blog has been posted exactly 100 days ago (or probably 101 when I'm finished with writing this post). And here's my compulsory sorry for that: Sorry.
I quit my job at 1&1 and moved to Hamburg to work for GoodGame Studios. So maybe this is some sort of excuse. The good part about this change is that I'm now working with Unity3D full time. It's great!
I synced my hobby development environment with my development environment at work: Unity3D, Visual Studio + ReSharper and GIT via Atlassian SourceTree.
My actual progress in Stranded III is quite limited. I'm still busy with doing TONS of refactoring. Yes, I noticed that I'm spending way too much time refactoring but I really want to have a rock solid, stable and clean base engine.
One new thing I added are visual graphs for debugging (FPS and network usage). Nothing special or extraordinarily fancy as you can see here:
I also decided to go a bit more into detail about the problems I face. Maybe it's interesting for some of you:
Today I spent some time having strong feelings about the incredibly annoying terrain engine from Unity. Using its terrain trees seems to be a very good idea for big maps because they are automatically rendered as billboards when they're far away. This way you get a nice framerate even with thousands of trees. Good.
The ugly part about it: You can't really do much with these trees. You can't use them properly with raycasting (like pointing with the mouse at them and interacting with them) and there is not even a simple and efficient way to remove single trees! What the hell where the Unity guys thinking? EVERYONE wants to destroy trees in games! Static trees are boring!
Wait! It even get's worse: It looks like you can't use assets for terrain trees which you loaded or created dynamically at runtime! This is really bad for modding because it makes it pretty impossible to make trees changeable. Maybe it's possible with so called asset bundles but these can only be created with Unity and they are annoying (+ maybe it only works with Pro - at least it used to be that way before Unity 5).
For the moment I decided to keep real objects for raycasting and collisions which are simply not rendered and to use the terrain trees just for the visualization. It works fine and also removing single trees works with some code. It's probably not the fastest thing to do but it doesn't cause noticeable lags with a few thousand trees so it's okay.
I'm not 100% happy with this solution though. It means that additional memory is used because all trees exist more or less twice. This doesn't seem to be a problem at the moment but... it's still ugly.
I probably have to do more testing and maybe I'll have to write my own terrain engine with own optimizations to get the results I want to see.
Well, thanks for reading!
Here's a totally unrelated and poorly made POTA... - NO! GIF! of (parts) of the lightcycle for your efforts! Fun fact: In the last frame you can see that I currently don't adjust the fog color perfectly at night - it's still too bright!
800x600 Version (~785kb)
Well.. I just thought about writing a new entry - even though I don't have much to tell and even less to show - and then my (self-written uber awesome) forum software came up with this fancy message:
So the last dev blog has been posted exactly 100 days ago (or probably 101 when I'm finished with writing this post). And here's my compulsory sorry for that: Sorry.
I quit my job at 1&1 and moved to Hamburg to work for GoodGame Studios. So maybe this is some sort of excuse. The good part about this change is that I'm now working with Unity3D full time. It's great!
I synced my hobby development environment with my development environment at work: Unity3D, Visual Studio + ReSharper and GIT via Atlassian SourceTree.
My actual progress in Stranded III is quite limited. I'm still busy with doing TONS of refactoring. Yes, I noticed that I'm spending way too much time refactoring but I really want to have a rock solid, stable and clean base engine.
One new thing I added are visual graphs for debugging (FPS and network usage). Nothing special or extraordinarily fancy as you can see here:
I also decided to go a bit more into detail about the problems I face. Maybe it's interesting for some of you:
Today I spent some time having strong feelings about the incredibly annoying terrain engine from Unity. Using its terrain trees seems to be a very good idea for big maps because they are automatically rendered as billboards when they're far away. This way you get a nice framerate even with thousands of trees. Good.
The ugly part about it: You can't really do much with these trees. You can't use them properly with raycasting (like pointing with the mouse at them and interacting with them) and there is not even a simple and efficient way to remove single trees! What the hell where the Unity guys thinking? EVERYONE wants to destroy trees in games! Static trees are boring!
Wait! It even get's worse: It looks like you can't use assets for terrain trees which you loaded or created dynamically at runtime! This is really bad for modding because it makes it pretty impossible to make trees changeable. Maybe it's possible with so called asset bundles but these can only be created with Unity and they are annoying (+ maybe it only works with Pro - at least it used to be that way before Unity 5).
For the moment I decided to keep real objects for raycasting and collisions which are simply not rendered and to use the terrain trees just for the visualization. It works fine and also removing single trees works with some code. It's probably not the fastest thing to do but it doesn't cause noticeable lags with a few thousand trees so it's okay.
I'm not 100% happy with this solution though. It means that additional memory is used because all trees exist more or less twice. This doesn't seem to be a problem at the moment but... it's still ugly.
I probably have to do more testing and maybe I'll have to write my own terrain engine with own optimizations to get the results I want to see.
Well, thanks for reading!
Here's a totally unrelated and poorly made POTA... - NO! GIF! of (parts) of the lightcycle for your efforts! Fun fact: In the last frame you can see that I currently don't adjust the fog color perfectly at night - it's still too bright!
800x600 Version (~785kb)