tisdag 18 januari 2011

Or not... :3

If there is anything in life i should know by now, is that just because something looks good, don't mean it has to be.

This is something i always forget, I get all excited about something, just to find out it don't work... and have my dreams shattered :(

The instancing incident looks to be exactly the same, it looks very good in theory, but not so much in application(at leasts not my application).

I'm sure some one could use instancing for the type of engine I'm working on, but i don't think it will be with SunBurn.

So what is the problem?

The problem lays in the structure of witch sunburn handles instancing(maybe this is the normal way, i have only tried instancing with SunBurn), SunBurn works with containers, each container may hold up to 75 objects, all these objects are basically one and the same but located at different locations and they all share the same effects.

in my solution, i had 2 ideas.

1. I have a per-chunk based solution, where every chunk kept track of the blocks in it.
This makes the most sense and is a clean and simple solution, here is an example:

our chunk is made from 256 block, 250 of them are stone and 6 are sand, this means we need 3 containers to store 225 stone, and one to store the rest 25 stone, we also need one container to store the 6 sand.
and you can see, this is ALLOT of wasted container space, and it would happen in evry chunk.

so, the optimal alternative would be.

2. We have one gigantic global multi-array of containers, and every block in the world is added to this array whenever needed, the waste would be as small as it could possible be, BUT it also means:

1# Forget chunk-based Occlusion!, it would be impossible to know witch chunk a block is located in, blocks are basically in a random mess somewhere in that array, and in no way correspond to a chunk, any chunk.

2# for the same reason, it would be very messy to make changes in the terrain, remove a certain block for example, however adding is simple.


There is one more thing that worries me, running the SunBurn instancing example, with 30.000 block gives me <40fps, this can be compared with the original minecraft witch renders 60-70.000+ at 60+ fps, and we don't even have half the objects... no good :3

so what does this mean?
well it means that even tho i love the idea of instancing, i don't think it will work with SunBurn for my needs.

Edit: It should be noted that i don't have anything against Instancing in SunBurn, and i might use it for other things... bonuses, drops on the ground, monsters, and so on... but not blocks in terrain.

måndag 10 januari 2011

I hate it when my friends are right :P

Oky good fokes, it is time for a change in minertopia land :)

My friend have been blabbering about this for ages(even tho i doubt he ever used it him self), so I'm sure he will gloat about the fact that i am now changing my mind and going with "his ways".

And i guess it Don't really help that i am normaly the "wise guy" who win all the discussion i have with him... that is, until this time... (oh there was that other time when i screwd up the XOR gates in Minecraft... but don't tell him i admitted defeat *makes hysshing sound*)

So... anyway... for a very long time, i have been stuck with manually generating my vertice data in xna, vertice for vertice.
This is how i learned things when i started using xna, and even if it tend to get a bit messy at times(indices for example) i still like having that level of control.

but for the minertopia project, I am now considering alternative and drastic changes.

I might be an old dog when it comes to learning new tricks, but I'm not totally immune to common sense(for the most part).

So what is changing? well, i have decided that a technique called Instancing is the way to go in rendering my blocks in minertopia.

For those of you who don't know what it means, it basically means that you tell your graphics card to render the same model in more than once place to make it look like more than one model.
this is very usefull if we for example need to render 100 monsters/bonuses/weapons that all look the same, or in our more relevant case: 70.000 blocks making up the world.

The cool thing about instancing is that you can render 10-20 times the amount of objects for the same performance it would take to render them as separate objects without instancing.

even more cooler is that the newly bought SunBurn Pro engine i got a little while back, support it as well :)

For those who care, here are my arguments for swapping.

  • Less programming needed, i can even create my cubes in 3d modeling software, and import them with Textures, normal maps(and more) without writing a single line of code to generate them(like i do now)
  • I'm no expert on Instancing yet(i have yet to read the small print on the subject), so correct me if I'm mistaking, but it should drastically decrease the amount of memory on GPU needed to store my world, currently it takes about 700mb for my whole world(yikes! yeas... but vertices's in SunBurn takes more space than normal ones in XNA), but with instancing, at least in theory(in my head anyway) it would probably not take much more memory than the coordinates take for each block, since the block data is the same rendered at different locations.
  • Lets face it, it makes perfect sense, if Instancing was created to render objects that looks the same multiple times, then what better scenario is there than a world made from blocks where most of them look the same... just like minecraft, seriously...(PS: Minecraft don't use Instancing)


One thing i liked about custom generated geometry, and was my main selling point for using it(that and stubbornness), was the fact that i want each block of the same type(stone for example) to look different from the stone block next to it, this to avoid the very visible repeat pattern you see in normal minecraft.

This was simple to implement if you generate each surface in real time, you simply randomly pick a texture in a texture atlas(i think minecraft works like this).

now, if we used whole cubes like I'm planning to use with instancing, we cant do this anymore, but instead what i will do is having 6 different textures on each side of the same cube, and randomly rotate it when placing it in the world.
This would give a similar effect for most of the scenarios, but it is not as good as the first approach.

There are ways to work around this, we could still render each surface separately using instancing, but i thought i would keep things simple for now.

This new direction should improve general performance, and make things allot easier for me, less programming and more playing around in 3d editors ;-)

The only downside i can think of is that it would make the game strictly 3.0 shader, but since i use normal maps and parallax maps(planning to anyway) i guess i already had that limit.


Edit:
As it turns out, from some early tests, the amount of memory is minimal when using instancing compared to custom geometry.
The world took around 700mb+ ram before.
Compared to now, wheres 70.000 block take only 23mb of ram!, not bad at all :-)


It might also be worth mentioning , that minecraft takes around 500mb of ram(last time i checked).

tisdag 30 november 2010

Don't you just love family sometimes?

For some time now i have been trowing longing looks at the SunBurn lightning and shadowing Engine for XNA, all the eye candy i could ever dream about, put together in one neat little package!

only problem? the PRO license was 300$ alone, and since i am very Very poor(stuck on welfare atm) and my family is not much better off, i was not sure i would ever be able to get my hands on it.

To be honest, 300$ is allot for my family at any given time, and it is proberbly 2-4x what i normally would get in total from my parents and grand parents together in xmas present...

until tomorrow that is, because my grand mother/father decided to help me out!


Since my goal with this project is to improve my current horrible economy and start my own company in the end, i guess they consider it money well spent, hooray! :D

So by this time tomorrow, i will be making the order at http://www.synapsegaming.com , for a SunBurn PRO license, sweeeet! :D


So what will i be able to do with it you ask?

How about: Deffered shadows for realistic real-time shadows, and Fill-lightning to mimic Radiosity(indirect lightning) like effects. it could look something like This(this movie is from the Crysis engine and not SunBurn, but the technique should be the same).

Normal & Parralax mapping for extra depth to textures, could look something like This(test I'm doing for the style on my stone blocks).

HDR rendering to emulate how our eyes work around bright light, this is the official SunBurn HDR tec demo(it also shows Deffered shadows), or you can check out a stalker video witch uses all of the above.

Al these eye-candy i get almost for free, with the awesome SunBurn engine, i cant wait until i got my hands on it! :D

fredag 5 november 2010

Minertopia: the begining

Only creating this blog to make sure the name 'minertopia' is safe until i have more info to share about this project :)

but i might as well summarize what mindertopia will have:


  • Real-time shadows, HDR, normal maps, HL2 like water, and other sweet eye-candy graphics.

  • More realistic textures in higher-quality.

  • Near-infinitive Procedually generated terrain.

  • Night & day cycles.

  • Whether effects such as rain/thunder storm, wind, snow(with real game-affecting attributes, ice/rain would make blocks slippery and so on).

  • Possibly seasons(winter, summer,autumn and so on)

  • Interesting and unique monsters rooming around during night.

  • Some form of crafting system.

  • Considering implementing ways to upload your creations, and distribute in other clients during Single-play(similar to Spore)

  • Will be a commercial project.

  • Awesome secret game element! I don't want to mention it just yet, because i don't want to risk that other people who make clones implement my feature before i do, but i have a feeling it will blow your mind! :)