Mythruna

Strange but true.

A slight discrepancy in how the fractal was processed into tiles means the all existing worlds are technically off by one block to the south east.  Whatever block you are standing on, the fractal equations really gave me the block to the north west... and I added one.  This probably seems like a small thing... and indeed, up until now it has had absolutely no affect.

The funny thing is that I happened to notice it as I was copying the terrain generation over to the new engine.  I even put a comment in about it and how it doesn't cause any issues... and then promptly moved on and forgot about it.  It didn't seem like a big deal and fixing it would make all existing worlds off by one block to the north west... which "might" manifest itself as a noticeable duplication of exact tile patterns along some border.

For the curious, this happens because in the process of turning fractal heights into terrain types, I need to search the surrounding blocks.  So I ask for a portion of the fractal 2 bigger each way than I actually need, ie: I wanted an extra 1 block border all the way around and then I'd just ignore the border when generating the tile itself.  The problem is that I didn't offset what I was asking for from the fractal.  Where I should have asked for the range starting at (-1,-1) I was asking for (0,0).

Anyway.

As you know, recently I've been working on refactoring how the trees were generated.  The existing released engine (hence forth known as 'the old engine'), does this as a last step of terrain generation.  The terrain is already generated, caves are carved out, and grass and plantable blocks figured out... and then I just plop the trees down in the tile based on a selection algorithm.  As noted elsewhere, there were some problems with this approach... trees couldn't cross tile boundaries, I had no idea where I'd actually placed trees: useful information for other things, etc..

The new approach figures out where the trees should be for the whole "node" (1024x1024 space) and just selects the right ones for tile generation.  They can cross boundaries because that tree will just get rendered in both tiles.

This is trickier than it sounds because the trees need to know about the caves.  A height map and terrain classification isn't enough.  So I had to go back to my cave algorithm and create an intermediate form where it carves the surface caves and gorges out of the height map... now the trees know where they should properly go.  It also now takes a bit of time to generate a node but that was inevitable.  All of that stuff is cached anyway and mostly speeds up all other tile generation.  Towns, buildings, and roads should easily double the time it takes to generate node descriptors but should only minimally impact tile generation.

So, anyway, I refactored the caves accordingly, modified the tree generator to generate a node-wide descriptor of where all of the trees are (approximately 15,000 trees in a node, by the way) and I was working on the tile-level generation.  All of it was finally coming together.

Then I noticed some of my trees were floating in the air.

Investigating, it looked like it was always a case where there was a raised area to the west or north... more specifically, west and north.  My previous issue came back to haunt me.

So now the fractal is universally located across the board... that means your existing worlds may end up with a slight seam (if you happen to notice it) between already generated and ungenerated parts.  Hopefully that's the only other change other than the trees.  ("I am altering the deal.  Pray I don't alter it further." http://www.youtube.com/watch?v=jsW9MlYu31g)

As an aside, this also fixed a little glitch, one of those little details that only I might notice, where the far-horizon terrain occasionally seemed to be one block off from the paging in real terrain...

Good work paul :P cant wait to have a play with the new engine :]

I hope to have a "friends of mythruna" version ready to play with in a few days.  It won't be fully functional or anything but enough to play with the new menus and fly around worlds and stuff.  Mostly I'm interested in performance comparisons and whether the new shaders work.

I'd do it now but when loading a world for the first time there is a long pause... like long enough to think the game is broken... because I haven't put in a loading progress bar or anything yet.

Minor panic attack just now:
-ran game
-performance was pretty bad
-thinks me, "Crap... what could I have done to halve my performance?"
-thinks me, "Clip is only 128, right?"

...um... no.

So, interesting fact: the new version of the engine remembers your clip setting from one run to the next.

This would be less funny if I hadn't been hit by this exact same panic at least three times now. :P

Great job, Paul, keep up the good work and don't scare yourself so much ;)

Pray you don't alter your clip further.

Will the game with the new engine have any conflicts with the old engines worlds, like say your servers world?

No, except newly generated areas will be one block "shifted" from already generated areas.  Mostly this will be unnoticeable.

I strive for backwards compatibility... indeed, I already have a 100 worlds of my own with various things I've built that I'd like to go back and extract some day.  Building ideas, ships, monkey tree houses, barns, etc..

Thanks for the update. Make sure to leave some testing for us  ;)

monkey tree houses seem interestingly specific... and fun  ;D

I think I posted pictures of those a long time ago.  I was playing with building a simian style house in a tree... theory, architecture, etc..  Kind of neat looking I thought.

Something similar to huts with bridges connecting them through the trees?

I found the picture on the facebook photo feed.  Not the best pic, though.
(http://i.imgur.com/0HBMEcm.jpg)

Oh wow. That would be neat for houses in areas with SMALL (Hint Hint Hint Hint Hint I SAID HINT!) trees. Hmm... Do you plan on (HINT!!!!!!) making (NOT A HINT!) bigger trees? Like ones that would be 2x2 or even 5x5 blocks around? THEN you could have these HUUUUGE trees! And if they were close enough together, then you could have whole CITIES on top of the trees! Oh, what about Thick Leaves? Thick enough for people to walk on and build on! Ohhh, so many ideas!

Oh wow. That would be neat for houses in areas with SMALL (Hint Hint Hint Hint Hint I SAID HINT!) trees. Hmm... Do you plan on (HINT!!!!!!) making (NOT A HINT!) bigger trees? Like ones that would be 2x2 or even 5x5 blocks around? THEN you could have these HUUUUGE trees! And if they were close enough together, then you could have whole CITIES on top of the trees! Oh, what about Thick Leaves? Thick enough for people to walk on and build on! Ohhh, so many ideas!
[/quote]

i agree, this would just be absolutely stunning. maybe not a whole forest of 5x5's but maybe near the center of the 2x2 mega forest? and the 5x5 is the main tree where the simian nobility live. or, since your making a huge tree anyway, maybe make the nobility tree 20x20 and have it mostly hollowed out so that the nobility can live there, and the rooms in the tree will be the equivalent of mansions to us.


once you start jumping back into lore and races you will see me a whole lot more on here  ;) i also think its a good idea to have a fan contest for a new race, and you can pick the best race of the entries to put into the game. i have seen it happen multiple times and this is the only game i reaaaally want to input some ideas!

The 8, I mean 7 races are kind of set in stone for the main game.  Maybe I'll feel differently about it when tons of money is rolling in and I have a team of artists... but as it is, a race represents many many months of work on its own.  And I haven't implemented even one yet.  :)

Thicker trees are hard because the geometry gets messy.  I want to do it on some level but there are a bunch of issues.  The new engine is more capable of doing it than the old was, though.

*Cough* Yes, the '7' races. But yeah, I'd like to see a new race maybe at some point. I'd say it should be thrown in secretly, like as a brand new race that popped out of the sky! Then you don't jave to worry about how they build or anything yet, because they didn't have time to build anything! :D

Yeah... I can see that. You CAN have just straight ones that are perfectly normal, so that's easy. But doing something like big winding trees would be a bit hard... Would be awesome to see them naturally at some point though :3...


On MC, their's a plugin called VoxelSniper, which is a really neat tool. It can be easily used to make HUUUGE terrain stuff, such as mountains or MASSIVE trees! They can have really weird shapes that you want and look natural! You can get even more precise if you want and have perfect archways ETC...

OMG!!! ^^^ Just gave me an idea!!! Maybe sometime after you get a lot of the Survival stuff set down, or Build Mode you could make a Terrain editor! Something like make a list of 'Oak Trees' or 'Oak Trees with Houses' and you can either pick something from the list, OR the list itself! If you pick the list then it will place down a random thing from inside of it where you clicked/place. :3

These already exist as admin tools.  I can place whatever kind of tree I want wherever... random buildings, too.

hm

It's no use. Paul has already made it so obvious. Or maybe he's playing us into a trap. Either way, win win.

You know he's going to make 7 races, then the 8th race FAR FAR FAR after release.. so we'll keep looking for it but give up... THEN it'll actually be there and we'll completely not see it xD

That's too far! D:

If you encounter it then there will be no mistaking it.

*cough* centaur.

You will also most likely have never seen it before.

well its settled then. the last race is an alien.

We are the only aliens.

They are definitely native to Mythruna and have been since "the before time, the long-long ago".  After all "the whispers" has worked its way into common Mythrunian culture.  It's one of the few things that is universal across the races.  Even a reptilian might wish a friend "a safe trip free of whispers".

Note that no current generation will have ever encountered one... nor their parents or parents' parents, etc..  Legend and lore by now.  Like the dragons.

Legends and folklore that you encounter as something extremely rare will be the best part. Instead of like skyrim where you get a telling of something legendary and then you get it a few days later.

Well, dragons are legends to native Mythrunians because they can't wake them up.  If you happen to be (un)lucky enough to find one early then suddenly legend will be reality really soon. :)

There was a time before the shattering (when Mythruna was just one world) where dragons were real, though not necessarily numerous and they would hibernate frequently.  The legends come from that time.

The whispers are not dissimilar.  They only show up in the world as a side-effect (and some chain of events I won't go into) of us being there.

I feel a plot-twist coming up. There's going to be treasure hunters looking for an ancient dragon and then suddenly instead of a dragon you get The Whispers.

Dragons are awakened by your direct presence.  The whispers are a side effect of something else.

Dialog.

How much farther can my fangs suck the urge to resist out? :D

My guess is the wispers are the clean up crew species that Paul had mentioned earlier this month.

That would be beyond cool

But it's not.  Those _creatures_ will be plentiful land obvious.

You may never actually encounter the whispers... though I have plans to make that a little more possible.

You should make a secret item available for accidental forging. Letting you see the whispers... Why am I portraying them as shadows.

They are 100% visible.

I think I'm going to stop talking now.

It's too late. We have your posts quoted all over the entire internet. Your plot has failed.

Any donators releases are going to be delayed a bit. 

I had only stubbed in lighting up until now.  It worked but only propagated within a leaf.  This led to some ugly visuals at the borders some times (really dark areas and stuff).

I had a rough design of how it should work for real but I finally started crunching on the detailed design last night.  I was only going to spend an hour or so on it but there were too many open questions it generated.... and some of them could have affected my whole lighting architecture decisions.  Those are the kinds of things that need to get nailed down sooner rather than later.

So last night I did a deeper design and tonight started implementing it.  It's worth finishing, though as that is one more thing done.  And it's one of those things that I would drag my feet on otherwise.  I have bad memories of how long it took me to get lighting working last time and it was never 100% right as it was.

The old engine did all lighting on the server and persisted it.  The new engine does all lighting on the client and never persists it.  The nice thing is that means mistakes can sometimes be self-correcting... or at the very least I can patch them in future versions without having odd lighting hanging around everywhere.

The other nice thing about doing it on the client is that I could do it differently for different races and abilities.  This was sort of a long-standing requirement of mine and I'm happy to finally be working towards that goal.  For example, races with infrared vision might see lighting and color completely different in the dark.  Low-light seeing races like pantherians may simply see better in dimmer conditions... light may propagate farther for them.  Anyway, universal lighting on the server was never going to allow that.

When I made that architectural decision, I chose to do some different things with my storage space that makes lighting propagation much much simpler.  So far this pays off nicely as all of my issues have been related to other things.  Basic lighting propagation is plenty fast so far.

Tonight I also started the support to do non-smooth lighting.  Ironically, this was trickier than it seems because the design decisions that freed up because of smooth lighting make non-smooth lighting very difficult.  But since lighting is done on the client and I want the light calculations to be very fast, I want the simpler option for lower power machines.  I really really want to get to the point where the lighting calculation is fast enough that I can have moving light sources like player-held torches.  Or objects that have light on them actually casting light, etc..

So if I'm successful with this phase, a bunch of long-standing issues become clearer and much easier to implement.

Ah, never knew you had such problems. Will moving lights on non-smooth lighting have gradual fading (Example: Will the lighting become gradually darker instead of having instant change depending on the distance from block) so it looks more natural? Or will it be linear? (When the light gets over the border of a different block the lighting instantly switches instead of the different block getting brighter as the light gets closer) If confused, I don't know how to explain it better.

I know what you mean.  Moving lights would still be block based.  But with smooth lighting, I still think it will look ok.

I think he was wondering if, without smooth lighting, blocks would increase their brightness gradually or in steps. When you place a light currently, the light looks like:
01210
12321
23432
12321
01210
As a light source moved, would the "numbers" go through fractions/decimals or simply jump from number to number?

That would be "not block based" since the lighting would have a position other than "block based".

Lighting will be "block based" meaning that a cell only has one light value.  If you move an object within that cell then the light value won't change.  If you move it out of the cell then the next cell gets the light value.

Right now I'm keeping two bytes per cell for lighting.  To do gradual (non-block-based) lighting, I would at minimum have to keep 8 bytes per cell... and that's only if I don't want colored lights anymore.  For colored lights, I would need to keep 16 bytes per cell.

32x32x32x16 is a lot of data just for lighting one leaf.

Hey Paul, has it got to that point that you are going to use 'bytes' and 'shorts', or have you already started using them at the beginning?

what else would I have used?

Actually, most of the cell data is stored as integers but that's multiple sub-byte values packed together.  The old version had 4 bits for sunlight, 4 bits for local light and the rest for cell value.

Yup, you got what I said. Thank goodness. I felt stupid.

I understood what you said, also.  It was pretty clear to me. :)

*gives award* :)

After a few days of false starts, I now have a working version of client-side lighting propagation.  It works at least as well as before but doesn't yet deal with block changes (efficiently)... and it's not as efficient as it could be in other ways.

But it's easier to optimize something that works than to optimize a work in progress that isn't even working yet.  And for now it's "fast enough" to move on to other problems for the time being.

I think the reason I hate lighting like this is because you take an idea so elegant and for performance reasons have to twist it into something so complicated and grotesque.  I can't even use the "it's hard to debug problems" excuse anymore because I now have a couple of nice ways to debug problems when they crop up.  Well, nice is relative in this case but I still have techniques I know will work to solve problems... which is more than I can say for when I wrote the first version almost two years ago.

Anyway, this is one to-do item that I'm really happy to have checked off.

Thats great news. Are you starting to see a specific date when we can hopefully expect an alpha release, or is that still past the horizon?

That's as far away as pluto..

I'm still not sure when I'll have the next pre-alpha ready. :(  It's been too long.

:'( It's all my fault..

Okay then. *Pats you on the back* At least Paul doesn't have himself to blame... *Cough* Actual paid full-time job *Cough*

I don't understand how you blame yourself for something you haven't even tampered with.

xD

Ding. +1 for post understanding.