• entries
    232
  • comments
    1462
  • views
    956526

Detail textures, step 4 (and a new panorama video)

Sign in to follow this  
Ysaneya

395 views

Not a lot of progress today, it's the week end, and i'm in a relaxing mood. Still spent an hour to fix a few things though.

The low orbit views are now back to looking decent. I thought to a trick yesterday evening in my bed, while trying to sleep: using a dynamic texture scale, instead of a constant one. This makes the repeating pattern disapear at high altitudes, because the texture repeats less quickly than at ground level. The scale is dependent on the depth of the terrain patch (ex.: at level 12 of the octree, the scale is x32; at level 11, it is x16; at level 10, it is x8, etc.. ). Of course, there are now seams between patches of different levels, but there was already seams before, and it's not really much visible. If that really becomes a problem later, i can still use a per-vertex scale instead of a per-patch one, so that the scale value is continuous.

I've added an alpha channel to the detail textures, that encodes the bumpiness of the terrain. These are combined together in a pixel shader, to make lighting more or less strong depending on the surface (ex.: rock has a lot of bumps while grass has very little).

The next "big thing" to do now is to fix the texture popping problems, using alpha blending.

I've made a new 360? panoramic video to show off the detail textures on "Mount Showwhite".

Get it here (15.2 Mb DIVX 4)

Warning: it's a high quality video, encoded at 3500 bits/sec in 800x600. Due to this, there was some slowdowns while recording the video, so you shouldn't be worried about the performance. In real-time on my computer it runs at 130-150 fps.


Sign in to follow this  


12 Comments


Recommended Comments

That mountain picture is gorgeous! I'm not sure I could think of a good algorithm for doing all those ground textures with the dirt patches in the snow and everything. That really looks good.

Are you eventually planning on putting in randomly generated trees and buildings on your planets?

I'm also wondering, since you are planning an Elite styled game; how long will the player be spending flying around on the surface of the planet, rather than out in space? Obviously with a terrain engine like that you'd be wanting the player to be spending heaps of time flying around in the atmosphere of the planet.

Share this comment


Link to comment
Quote:
Are you eventually planning on putting in randomly generated trees and buildings on your planets?


Yes, if look at some pictures a few months old, you'll see i had a prototype with trees. They were just billboards, but i plan to make "real" 3D trees (procedurally generated, so that different planets have a different fauna/flora). There will also be cities with buildings.. if i can find some good modelers to make them, of course (if not, i'll have to do them procedurally.. will loose a few months!).

Quote:
how long will the player be spending flying around on the surface of the planet, rather than out in space?


I don't know exactly, i'll try to keep a good balance. But you can be sure that, with all the time i'm spending working on a planetary engine, it's not to be left unused in the game :)

Share this comment


Link to comment
Damn, that is a very fine mountain you've got there. I hope you dont mind me asking what kind of algorithms you using for the texturing?

Share this comment


Link to comment
That is one nice panorama. Have you tried implementing a "fixed time step" system for videos? I had to build that into an engine a couple of years back - so that I could simulate 30hz through the reference rasterizer. Took hours and hours (and a few more hours) to render, but once done it looked perfect [grin]

Quote:
i plan to make "real" 3D trees (procedurally generated, so that different planets have a different fauna/flora).
I'm really looking forward to seeing what you can do with this. You've come up with some impressive stuff already, but this could just be amazing.

I can imagine it really setting the "tone" of a dark, barren, rocky planet that has little plant-life... through to a "eden" like planet covered in rich fauna and trees [oh]

Jack

Share this comment


Link to comment
Hmmm. If there are billions of planets in the system that are procedurally generated, how will you be able to maintain a database of all the buildings, cities and whatever else is going to populate a particular planet?

For that matter, how will the physics of the planets be handled? Each planet will need to keep its own state for position, orientation and so on. Multiply that by x^9 planets and there are some pretty huge storage requirements.

Although, judging from your work up to this point, I think you'll be able to come to workable solutions.

Just as a side note, with billions of planets zipping around in this virtual universe - what happens when two planets collide... that would be the coolest thing ever to watch a super nova triggered by planet collisions into stars! The residents of the MMO world could gather to watch the astronomical events! Keep up the good work, you already have me excited about the possibilities.

Share this comment


Link to comment
On that thought, large asteroid impacts on populated planets would be a fun event for the players too. Especially to find where it's going to land and get yourself squished :) Or better yet, ride down on the asteroid itself.

Anyway, the texturing is looking very nice now. You've certainly made some good progress in the past month.
The snow looks a bit grainy to me though. Maybe you could run it through some filters to make it a bit more "clumpy" around the edges. Something along the lines of the facet filter in photoshop, if you've used it.

Share this comment


Link to comment
Gaheris:

Quote:
I hope you dont mind me asking what kind of algorithms you using for the texturing?


That's going to be a bit complex to explain, so i'll make a simple summary, and i'll try to write an article for gamedev in the coming weeks.

Main idea: per-pixel texture splatting (if you are not familiar with per-vertex texture splatting, find an article on the web: what i'm doing is very similar, but is done per-pixel on the GPU instead).

Initialization phase:
- loading up N textures (layers), like grass, rock, snow, etc..
- creating a set of rules with some constraints about the slope/altitude of the terrain and which apply to a specific layer. For example, you find grass at low-altitude and flat areas, and snow at high-altitude and flat areas. Check out for Terragen if you want an idea of what kind of rules could be used.
- creating a set of weight textures; each layer is assigned a color component in one of the weight textures (weight0.r = grass, weight0.g = water, weight0.b = snow), etc.. For each texel in each weight texture, calculate the corresponding weights. All the weights must add to 1 for proper blending.

Generation phase (when a new patch is generated, ie once every N frames):
- each terrain patch is 33x33 vertices and has a unique 256x256 (or 512x512) renderable texture assigned to it.
- enable rendering to the unique texture, generate a 33x33 normal+height map (normal=rgb, height=a)
- upsample this 33x33 texture to match the unique texture size, ie. 256x256. This is done in a pixel shader with a bilinear filter.
- add noise to the normals and the heights. This is done in a pixel shader using many octaves of a tiling noise texture at different frequencies.
- use the normal/height map as input to the weight tables, and get for each layer its associated weight
- combine all these layers together in a pixel shader using a serie of multiply-and-add instructions.
- add per-pixel lighting and misc. effects

Render phase:
- render the terrain patch with its unique texture

Share this comment


Link to comment
Quote:
Have you tried implementing a "fixed time step" system for videos?


Not yet, i'm using FRAPS to record them in real-time right now, and as you guess performance suffers "a bit" :)

Quote:
If there are billions of planets in the system that are procedurally generated, how will you be able to maintain a database of all the buildings, cities and whatever else is going to populate a particular planet?


Planets will not be loaded into the DB until somebody discovers it for the first time. Planets will be unloaded when nobody has visited the system after N days/weeks/months/i don't know yet.

Quote:
what happens when two planets collide


They won't collide: they will all have stable orbits. The game takes place at human time scales anyway, and the probability of "seeing" this kind of event happens is extremely low. However, i plan to implement some more frequent events (like asteroids crashing on planets, eclipses, etc.. ).

Quote:
The snow looks a bit grainy to me though. Maybe you could run it through some filters to make it a bit more "clumpy" around the edges.


That's true, but i tried to give it a Terragen-esque look (if you look carefull at Terragen pictures, you'll see it's a bit grainy too). I'm tired of seing layers of textures blend together in a blurry mess :)

Share this comment


Link to comment
Awesome, thanks a lot for the overview over your texturing algortithm! It sounds like a pretty good way of doing it. I'm sure a lot of people would be pleased if you wrote an article about it someday.

Share this comment


Link to comment
Just finished watching the panorama.... BREATHTAKING!!!

Are you planning on allowing the player to directly interact with this content or are you confined to your ship? I know it would probably be asking too much, but these screenies make me want to go hiking. [smile]

Share this comment


Link to comment
Quote:
They won't collide: they will all have stable orbits. The game takes place at human time scales anyway, and the probability of "seeing" this kind of event happens is extremely low. However, i plan to implement some more frequent events (like asteroids crashing on planets, eclipses, etc.. ).
Don't shot the messenger, I saw this article today.
Quote:
There’s room in the universe for thousands of galaxies but that doesn’t stop them from running into each other. New observations support the idea that galaxies are in constant interaction with each other and that the biggest ones get bigger by engulfing smaller ones.
(full article)

Share this comment


Link to comment
Actually... from the same article:

Quote:

These observations also show that these merges happen fast — which is probably why they were difficult to spot before now.

"Well, fast is a few hundred million years. That’s fast compared to the age of the universe," van Dokkum said. While that doesn’t seem very fast, it’s quick enough to account for those old, massive galaxies.


So on the scale of galaxies and relative movement of stars, the Universe can be pretty static and no one will notice :)

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now