New Terrain Early Shots

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!

New Terrain Early Shots

Postby sinbad » Tue Jun 16, 2009 7:02 pm

Some of you already know I'm working on a new core terrain system, and it's starting to finally bear some visual fruit.

Some of the things that it benefits from over the old TerrainSceneManager:
  • SceneManager-independent, separate optional component (OGRE_HOME/Components/Terrain)
  • Integrates with (optional) Paging component
  • Inherently editable - a lot like ETM ;)
  • Hierarchical geometry batching; batch counts reduce at lower LODs as well as vertex count. At the lowest level of detail, the entire terrain page is a single batch which has obvious advantages for large paging terrains over the fixed tiles previously used. There's also the opportunity to go to a lower overall resolution and to drop detail geometry in the far distance compared to non-hierarchical approaches.
  • Skirts are used instead of stitching to avoid cracks in geometry; this means fewer indexing arrangements & lower overall index buffer usage
  • In-built support for splatting layers, configurable sampler inputs and pluggable material generators
  • Support for generating global normal maps and light maps in a background thread
  • Saving & loading of terrain built in, including loading / processing in a background thread
  • LOD now adapts in real-time to camera settings (viewport sizes & LOD bias) so you can use the same terrain with multiple views efficiently
The example material generator will support normal / parallax mapping and specular mapping on all splatting layers, given the appropriate hardware. Provided I can fit it into the instruction limits, we should be able to apply up to 6 layers in one pass in this fashion. Here's some of my early tests (not polished yet, just tech proofs really).
[edit]Shots updated 18 June[/edit]
newterrain_6.jpg
newterrain_6.jpg (121.04 KiB) Viewed 44117 times
newterrain_7.jpg
newterrain_7.jpg (135.2 KiB) Viewed 44117 times


You can probably make out the normal mapping and specular mapping there (big rocks are shiny, dirt is not). Parallax mapping isn't in there yet, but is trivial to add. I'm packing diffuse and specular textures into one sampler, and the same with normal/displacement. Shadow mapping and atmospherics are also missing so far, but the lighting is fully dynamic.

The issue I have at the moment is that I've avoided using vertex normals and used a global object-space normal map instead, because when LOD is involved vertex normals produce obvious lighting variations as the geometry simplifies. A global normal map gives 100% consistency at any distance, but the downside is that I have to generate the tangent space basis in the pixel shader. With the normal mapping too, I've found that I can't fit inside the ps_2_0 instruction limit and am currently using ps_2_x. Any modern card will handle this easily of course, but it would be nice to be able to support ps_2_0 too.

I already have to investigate material LOD later, since it's a total waste to be doing normal / parallax mapping all the way to the horizon. My current thought is that I might use the object space normal map for the non-normal mapped distance version, and use per-vertex normals and tangents close up, when tesselation might be stable enough not to be an issue. However, this would make the per-vertex overhead of each terrain page increase by a large amount (currently I just store position, UV and will add optional vertex colour later). So, I may not go down that route and just require ps_2_x or above for full normal mapping.

Obviously we'll have fallback fixed-function options too. And, you can write your own material generators - a deferred render material for example.

It's not ready for prime time yet, but it's getting there. Feel free to play with it (test is PlayPen), but bear in mind it has a number of minor bugs and I'm not finished yet. But, I think it's going to be pretty cool.

For this message the author sinbad has received 6 kudos
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 19257
Kudos: 68
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: New Terrain Early Shots

Postby KungFooMasta » Tue Jun 16, 2009 7:21 pm

Awesome! I can't believe I'm the first to reply on this thread! As we speak I'm fixing up my project to remove the old terrain solution and start learning how this new system can fit into my framework. :D
Creator of QuickGUI!
User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
 
Posts: 2087
Kudos: 16
Joined: 03 Mar 2005
Location: WA, USA

Re: New Terrain Early Shots

Postby nikki » Tue Jun 16, 2009 7:42 pm

KungFooMasta wrote:Awesome! I can't believe I'm the first to reply on this thread! As we speak I'm fixing up my project to remove the old terrain solution and start learning how this new system can fit into my framework. :D

Argh... I saw it before you replied, then I was thinking "I'll reply later, gotta eat.". :x

Anyway, nice stuff Sinbad! Not much of a terrain guy myself, but I'm sure it'll be useful for many other people.
User avatar
nikki
Old One
 
Posts: 2730
Kudos: 13
Joined: 17 Sep 2005
Location: Princeton, New Jersey, USA

Re: New Terrain Early Shots

Postby spong3bob » Tue Jun 16, 2009 7:47 pm

Thats exactly what i was searchin for :P
cant wait for the first released version..
will there be a limit on how many different materials there can be splatted?
spong3bob
Gnoblar
 
Posts: 5
Kudos: 0
Joined: 16 Jun 2009

Re: New Terrain Early Shots

Postby Praetor » Tue Jun 16, 2009 7:47 pm

Looking really good sinbad. I'm just waiting for a signal that this is ready for initial testing I'll try it out. As for your shader problems, I'll direct you here: http://blog.gamedeff.com/?p=78. 8 lights, diffuse, specular, attenuation, normal map with SM2.0. Impressive to say the least. Luckily he chronicles how he does it, and perhaps some of the techniques he has in there you can use to cut down your instruction count.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 3335
Kudos: 3
Joined: 21 Jun 2005
Location: Rochester, New York, US

Re: New Terrain Early Shots

Postby Kencho » Tue Jun 16, 2009 8:00 pm

Ooooh great!I'm not a terrain-guy either but this is getting me interested :)
Image
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
 
Posts: 4011
Kudos: 1
Joined: 19 Sep 2003
Location: Burgos, Spain

Re: New Terrain Early Shots

Postby buckED » Tue Jun 16, 2009 8:04 pm

I have been looking for a good terrain solution forever.
This sounds promising. Waiting to see more :)
Thanks a lot for this great addition.
User avatar
buckED
Greenskin
 
Posts: 133
Kudos: 0
Joined: 15 Feb 2008

Re: New Terrain Early Shots

Postby Jabberwocky » Tue Jun 16, 2009 8:23 pm

Very cool. These are great improvements. I'm looking forward to building some larger terrains than allowed by the old TerrainSceneManager. It will be interesting to see how the batch count helps framerate, particularly on a fully-populated landscape where batch count is a key performance issue. What sort of controls are provided to specify LOD transitions?

Is a "material generator" some c++ code that outputs a material, perhaps generating some shader code based on some kind of config file parameters?

Requiring ps_2_x for normal mapping would be a non-issue for me. I wonder if any card unable to support ps_2_x would have performance issues with a normal mapped terrain anyway.

The paging component is really exciting as well. You've done a great job designing it in such a way that it will be useful for other non-terrain-based scenarios in the future.
Image
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
 
Posts: 2819
Kudos: 216
Joined: 05 Mar 2007
Location: Canada

Re: New Terrain Early Shots

Postby nikki » Tue Jun 16, 2009 8:33 pm

Jabberwocky wrote:Is a "material generator" some c++ code that outputs a material, perhaps generating some shader code based on some kind of config file parameters?

Yup. You could stitch a shader together instead of doing it the '#define's way, for example. Also, often you have to create many materials for each permutation of shaders (Plain, NormalMapping, Shadowed-Plain, Shadowed-NormalMapping, etc.), it could help with that too.
User avatar
nikki
Old One
 
Posts: 2730
Kudos: 13
Joined: 17 Sep 2005
Location: Princeton, New Jersey, USA

Re: New Terrain Early Shots

Postby denreaper » Tue Jun 16, 2009 9:13 pm

This is exactly what Ogre3D needs. Most other paging terrain solutions are bloated, buggy, or incomplete.

Awesome job, sinbad!
User avatar
denreaper
Greenskin
 
Posts: 105
Kudos: 0
Joined: 31 May 2006

Re: New Terrain Early Shots

Postby sinbad » Tue Jun 16, 2009 9:25 pm

Thanks for the feedback.

spong3bob wrote:will there be a limit on how many different materials there can be splatted?

There is theoretically no limit, but it depends on what your material generator has been designed to handle. I'm concentrating on high-quality terrain, so whilst if I was doing basic splatting I could probably do 12 layers in one pass, I can only realistically do 5, maybe 6 with normal/parallax and specular mapping plus shadows. Now, you can of course do more than one pass if you want more, but with my generator I'm shooting for primarily single-pass terrain if I can. This is all changeable with pluggable material generators and you're free to define your own texture layouts if you want.

@praetor: thanks - I have the extra challenge of generating based on the number of actual layers so hand-tweaking is a little more awkward, but I'll see if I can't learn something from that link. I've seen it before but it's always good to review these things.

Jabberwocky wrote:What sort of controls are provided to specify LOD transitions?


It's a max pixel error metric again - this seems to be the simplest, and of course it automatically adapts based on the viewport size (better than the old TSM did).

Jabberwocky wrote:Is a "material generator" some c++ code that outputs a material, perhaps generating some shader code based on some kind of config file parameters?


Yes. It's a 2-way thing - the generator is a C++ class which tells the Terrain object what information it needs (normals, light maps), and the terrain tells the generator how many layers there are, and what is in them. The generator also uses a 'profile' class which is sort of like a material technique or material scheme, but higher level because each one can request different types of data. A fixed-function profile might request a fully generated static lightmap for example, whilst a higher end profile would request a global normal map plus use shadow maps instead so it can use dynamic lighting.

Requiring ps_2_x for normal mapping would be a non-issue for me. I wonder if any card unable to support ps_2_x would have performance issues with a normal mapped terrain anyway.

I'm glad you feel that way - I was leaning towards this after I wrote this post, especially as the data overhead for adding normals and tangents to the vertices would not be insignificant for large terrains (and we'd still need the global normal maps for distance anyway). So I'm going to stick with generating the tangent space in the pixel shader, it adds a fixed overhead to the pixel shader but it actually runs really well (see the frame rates in the shots, on a 9800 GX2), and each layer doesn't add too much more cost.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 19257
Kudos: 68
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: New Terrain Early Shots

Postby DanielSefton » Tue Jun 16, 2009 10:24 pm

I've been closely following every commit - seeing a screenshot is refreshing. :) This is going to be a massive boost for my project, which requires gigantic terrains.

Using PLSM I noticed that it has quite a performance hit (high batch count oddly) - that's even without any material stuff. I'm shocked seeing your ~20 batch count! Also the obvious fact that it's difficult to get the terrain surface looking good with PLSM, and PSSM shadowing is a royal nightmare.

I'm watching MyRiddin's plugin too, but it's obvious that your approaches are more efficient. I guess the main difference is the extra shaders. We're going to be spoilt for choice soon. :P

It's as good as I can get it looking with PLSM; bring on normal mapping. :P

Image
User avatar
DanielSefton
Ogre Magi
 
Posts: 1235
Kudos: 10
Joined: 26 Oct 2007
Location: Mountain View, CA

Re: New Terrain Early Shots

Postby jacmoe » Tue Jun 16, 2009 10:56 pm

I saw the Ogre development tweets about shiny rocks (and waxed grass) - I've been expecting some screen shots! :P

It looks far better than I could have imagined! :D
Say hello to details.

I love your work, Sinbad. Really looking forward to using it.
And greetings to the contractor, making it possible. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
 
Posts: 20570
Kudos: 181
Joined: 22 Jan 2004
Location: Denmark

Re: New Terrain Early Shots

Postby Nauk » Tue Jun 16, 2009 11:35 pm

AhaaaAa... Getting somewhere, looks very good this far :) Is this the latest SVN in the screenshots or still a private version?

@DanielSefton: Very nice screenshot :)
User avatar
Nauk
Gnoll
 
Posts: 647
Kudos: 25
Joined: 11 May 2006
Location: Bavaria

Re: New Terrain Early Shots

Postby trilobite » Wed Jun 17, 2009 7:24 am

Sinbad, your new terrain system is going to be be a huge step forward for Ogre. We are all hungry like wolves for meaningful progress in the Ogre terrain department.

Beauty is one thing, physics is another. A big question of mine is how to get existing physics (OgreNewt, for example) to shadow and match dynamically rendered terrain. (Is this the solution nVidia is seeking by "integrating" PhysX?)
Or, will this new terrain rendering system simplify physics integration? (Now I'm really dreaming.)
Or, will existing physics (OgreNewt, OgreOde, nxOgre, OgreBullet) need to be modified in order to work with this beautiful terrain renderer?
Or, will we be needing a whole new kind of physics model altogether?

Thankful so many creative people are involved here...
User avatar
trilobite
Silver Sponsor
Silver Sponsor
 
Posts: 135
Kudos: 1
Joined: 13 Jul 2006
Location: San Juan Capistrano, CA, USA

Re: New Terrain Early Shots

Postby mikeInside » Wed Jun 17, 2009 8:09 am

I've got nothing original to say, but I would like to echo the following sentiments:
This is going to be a massive boost for my project

seeing a screenshot is refreshing.

Looking really good sinbad. I'm just waiting for a signal that this is ready for initial testing & I'll try it out.

This is exactly what Ogre3D needs

And greetings to the contractor, making it possible.

Awesome job, sinbad!


Image
User avatar
mikeInside
Kobold
 
Posts: 37
Kudos: 0
Joined: 26 Apr 2007
Location: Sydney, Australia

Re: New Terrain Early Shots

Postby koirat » Wed Jun 17, 2009 9:28 am

Great job.
This is a good news to me.

You could just add nicer textures to better advertise your work :) (my 5 cents)
This is a block of text that can be added to posts you make. There is a 255 character limit.
User avatar
koirat
Orc
 
Posts: 446
Kudos: 13
Joined: 25 Feb 2008

Re: New Terrain Early Shots

Postby stealth977 » Wed Jun 17, 2009 9:42 am

Well, its great job :)

I think the screenshots are from your private demo since the Playpen test doesnt show normal maps etc (PS 3.0 here)...

I already implemented a test class CPagedTerrainEditor in the new framework of Ogitor, will keep you updated about the problems i come across (already posted the first problems as PM) :)

Anyway it was nice seeing it in Ogitor, gives energy to implement more of it :)

ismail,
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
User avatar
stealth977
Gnoll
 
Posts: 633
Kudos: 40
Joined: 15 Dec 2008
Location: Istanbul, Turkey

Re: New Terrain Early Shots

Postby sinbad » Wed Jun 17, 2009 10:06 am

trilobite wrote:Beauty is one thing, physics is another. A big question of mine is how to get existing physics (OgreNewt, for example) to shadow and match dynamically rendered terrain. (Is this the solution nVidia is seeking by "integrating" PhysX?)
Or, will this new terrain rendering system simplify physics integration? (Now I'm really dreaming.)
Or, will existing physics (OgreNewt, OgreOde, nxOgre, OgreBullet) need to be modified in order to work with this beautiful terrain renderer?
Or, will we be needing a whole new kind of physics model altogether?


I've (I think) made it easy to extract the data you need from the terrain geometry in order to build physics objects from it. At the end of the day the terrain is one big patch of triangle strips, which I just split up to fit within 16-bit index limits (for efficiency and compatibility) and batch up based on an internal quadtree. You can extract all this information from the terrain page so physics integration is doable. You can also perform height queries and ray tests using the internal calculations.


stealth977 wrote:I think the screenshots are from your private demo since the Playpen test doesnt show normal maps etc (PS 3.0 here)...


Nope, this is the PlayPen demo. But as I say, all WIP, there may be hardware incompatibilities yet (and GL needs fixing which I'll be doing today). I'm only testing this so far on a GeForce 9800 GX2 right now.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 19257
Kudos: 68
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: New Terrain Early Shots

Postby sinbad » Wed Jun 17, 2009 10:28 am

DanielSefton wrote:Using PLSM I noticed that it has quite a performance hit (high batch count oddly) - that's even without any material stuff. I'm shocked seeing your ~20 batch count!


That's slightly contrived because the shots were taken to show the normal mapping rather than the distance rendering, which currently looks a bit dull because of the lack of atmospherics and some obvious texture tiling (which will be reduced using a separate global colour map later - I was going to use vertex colours but thinking about it that will look crap with the LOD just like vertex normals would).

However, even though that's contrived the worst case scenario on this terrain is about 40 batches when you're close up (although that includes the overlay and skybox too, which account for 10 ish). As you get further away it drops off, theoretically to 1 batch eventually if you let it get far enough away, but I expect mid-distance pages will sit at around 4-12 batches each which isn't too bad.

Batching is also highly configurable, since you set a 'min batch size' and 'max batch size'. These 2 metrics determine how much the terrain is split up. A batch is any patch of triangles at a hierarchy level. The leaves of the quadtree that represents the hierarchy can range from the maximum batch size, to the minimum batch size at their lowest LOD, and then after that 4 adjacent patches at the min batch count get grouped into one parent patch at the min batch size to drop LOD. So, a large difference between the min and max batch size gives you more LOD levels at lowest level of the quad tree, so more flexibility in LOD picking (because each low-level patch can make its own LOD decision - when moving up the tree all 4 patches have to agree that it's time to drop LOD for it to happen), but at the expense of less efficient batching. You can tweak the absolute and relative values of these batch sizes to get the balance you need between vertex count and batch count.

I'm not sure if this is a 'new' technique at all but I couldn't find any good papers on doing it like this, so I wasn't sure how well it was going to work. It seems to be working out well though.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 19257
Kudos: 68
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: New Terrain Early Shots

Postby sinbad » Wed Jun 17, 2009 10:36 am

koirat wrote:You could just add nicer textures to better advertise your work :) (my 5 cents)


Hmm, these were what I consdered 'nicer' textures to demo this, they're from the NVidia texture library and I generated normal/height and specular maps for them. But, I realised I screwed up the lighting calculation and my ambient was washing out the diffuse somewhat so they didn't look as nice as they should. Here's a better shot:
newterrain_4.jpg
newterrain_4.jpg (134.13 KiB) Viewed 44550 times


I need to get more interesting fading between the layers rather than the smooth fade here, but it's programmer art and generated in code (generating the blend map via a simple height-based fade) :) Hopefully you'll be able to get better results when editors start using it.

For this message the author sinbad has received kudos
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 19257
Kudos: 68
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: New Terrain Early Shots

Postby bishopnator » Wed Jun 17, 2009 10:40 am

Hi, it looks awesome :)) I am working on heightmap rendering in our product (golfblaster3d). Unfortunately I can't share source codes :( but I want share some ideas ;-)

1. reducing draw calls
It is possible to improve performance by batching lower LODs to singe draw call. I prepared "special" vertex buffer which contains same terrain block copied multiple times. For example for lowest LOD vertex buffer contains 4 vertices per block. Number of blocks depends on number of contant register which can be used for shader instancing. Each vertex contains except basic parameters (position - without height (just xz), uv, ...) also instance index and vertex index. Vertex shader has "special" input parameters - array of data for instances (transformation), array of heights). If in camera there are visible 20 blocks in lowest LOD and shader supports 40 instances, all blocks can be rendered by single draw call.

Sample shader (from my implementation):
Code: Select all
VS_OUTPUT  main_ver1_vp(VS_INPUT i,
                   uniform float4x4 worldViewProjMatrix : register(c0),
                   uniform float4 vInstancePos[40] : register(c4),
                   uniform float4 vInstanceHeight[205] : register(c45))
{
   VS_OUTPUT o = (VS_OUTPUT) 0;
 
   // compute world position
   o.vPos.xz = i.vPos.xy + vInstancePos[i.vInstanceData.x].xy;
 
   // packed heightmap data
   o.vPos.y  = vInstanceHeight[i.vInstanceData.y].x;
   o.vPos.w = 1.0f;
 
   // transform the position
   o.vPos = mul(worldViewProjMatrix, o.vPos);
      
   // pass texture coord
   o.vUVColorMap = i.vUVColorMap + vInstancePos[i.vInstanceData.x].zw;

   return o;
}


This approach can be applied also to lower lods - it depends only on amount of vertices in blocks. My shader needs only 4 registers for transformation matrix. Using vs_2_0 model it is possible to use 256 constant registers. These regs must be splitted to heights array and array with transformation for instances. Equation for computing number of instances supported by shader: N = 252 / (V + 1) where V is number of vertices per block in given LOD.
LOD0 (lowest) needs 4 vertices per instance, N = 50
LOD1 needs 9 vertices; N = 25
LOD2 needs 25 vertices; N = 10
etc.

As you can see, only one float from heights registers is used in shader - using other components (yzw) significantly increases number of supported instances per shader. If each vertex contains also index of component (0-3), than it is possible to set correct height value in vertex shader.
Code: Select all
  // compute world position
  o.vPos.xz = i.vPos.xy + vInstancePos[i.vInstanceData.x].xy;
 
  // packed heightmap data
  if(i.vInstanceData.z == 0) {
    o.vPos.y  = vInstanceHeight[i.vInstanceData.y].x;
  } else if(i.vInstanceData.z == 1) {
    o.vPos.y  = vInstanceHeight[i.vInstanceData.y].y;
  } else if(i.vInstanceData.z == 2) {
    o.vPos.y  = vInstanceHeight[i.vInstanceData.y].z;
  } else {
    o.vPos.y  = vInstanceHeight[i.vInstanceData.y].w;
  }
  o.vPos.w = 1.0f;

With this modification it is possible to draw up to 252/2 = 126 terrain blocks in lowest LOD in single draw call (1 reg is used for instanced data (block's transformation) and 2nd reg contains all 4 heights for vertices). In my implementation I created 4 different versions of vertex shader - 1st uses only 'x' component from register for heigths, 2nd uses 'xy', etc. because adding 'if' conditions to shader adds a lot of instruction to compiled asm shader. Vertex shader type used for rendering is determine only by amount of visible terrain blocks which can be batched using this technique.

2. material LOD
It is nothing special :)) I just rendered whole terrain into single 4096x4096 texture (or in maximum supported size) and switch pixel shader for further blocks. It reduces splatting / paralax mapping / normal mapping on whole terrain. Our shaders are not very fast and this approach significantly improved fps because these slow shaders are used only in short distance around camera.

3. memory reduction
I existing TerrainSceneManager vertices contains XYZ (floats), UV, normal, etc. (maybe some componets are optional, but it is not important). Using floats are really not very efficient. I am using following vertex format which I think it is sufficient for most implementations:
Code: Select all
struct VS_INPUT
{
  short2 pos    : POSITION;     // xz coord
  float  height : TEXCOORD0; // y coord
};

Vertex shader than accept 4 floats for transforming grid position to world position:
Code: Select all
uniform float4 vTerrainBox - xy = offset, zw = square size

float4 world_pos;
world_pos.x = vTerrainBox.x + i.pos.x * vTerrainBox.z;
world_pos.y = i.height;
world_pos.z = vTerrainBox.y + i.pos.y * vTerrainBox.w;
world_pos.w = 1.0f;


UV for mapping textures can be computed also in vertex shader from vertex's world position:
Code: Select all
float2 computeUV(float2 worldPosXZ, float4 vOffsetTilingColor)
{
  float x = (worldPosXZ.x - vOffsetTilingColor.x) / vOffsetTilingColor.z;
  float y = (worldPosXZ.y - vOffsetTilingColor.y) / vOffsetTilingColor.w;
  return float2(x, y);
}

If you want only planar texture mapping this is enough - it is not necessary to get UV from vertex buffer. So classic vertex (XYZ and one UV = 20 bytes per vertex) can be reduced to 8 bytes.
User avatar
bishopnator
Goblin
 
Posts: 217
Kudos: 4
Joined: 26 Apr 2007
Location: Slovakia / Switzerland

Re: New Terrain Early Shots

Postby stealth977 » Wed Jun 17, 2009 11:07 am

I wanted to post the first screenshot of the OgreTerrain (except the creators screenshot) :)

ogreterrain.png
ogreterrain.png (201.77 KiB) Viewed 44459 times


BTW, the FPS is at DEBUG build, and i am on a laptop with a not so decent GPU!!!!

ismail,
Last edited by stealth977 on Wed Jun 17, 2009 12:52 pm, edited 1 time in total.
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor

For this message the author stealth977 has received kudos
User avatar
stealth977
Gnoll
 
Posts: 633
Kudos: 40
Joined: 15 Dec 2008
Location: Istanbul, Turkey

Re: New Terrain Early Shots

Postby sinbad » Wed Jun 17, 2009 11:33 am

@bishopnator: thanks for the ideas. The instancing could be tricky with the batching I'm already doing but I'll certainly think about it.

Better vertex compression is definitely on my list of early enhancements. I'm still passing a single UV because it was easy, but I already multiply it out by a per-layer scaling to allow different tiling levels per splat layer so parameterising if from world position would be fine too.

@stealth977: good to see in another application :) Your washed out textures will be fixed if you update from SVN though.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 19257
Kudos: 68
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: New Terrain Early Shots

Postby AshMcConnell » Wed Jun 17, 2009 12:26 pm

Looks fantastic Sinbad, keep up the good work!
All the best,
Ash
User avatar
AshMcConnell
Hobgoblin
 
Posts: 511
Kudos: 10
Joined: 14 Dec 2007
Location: Northern Ireland

Next

Return to Showcase

Who is online

Users browsing this forum: No registered users and 1 guest