Outerra forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Download Outerra Tech Demo. Unofficial Outerra Discord server, MicroProse Discord server for OWS.

Pages: 1 2 3 [4]

Author Topic: Cartographers stuff  (Read 56820 times)

Redrobes

  • Member
  • **
  • Posts: 73
    • http://www.viewingdale.com
Cartographers stuff
« Reply #45 on: May 31, 2011, 07:35:41 am »

I think the situation is a little more complex than that and cant be predicted accurately with a spot check bit of math probability. The feed of the snow and collection of it is important. See this pic for a good example.

http://i21.servimg.com/u/f21/14/11/62/01/01_ste10.jpg

We try to make the same calculations for it like this:

http://me-dem.me.uk/galleries/gts/3DTexDemo045.png

and we could give you these masks to help guide your texture engine. Well, were all a long way off of being ready so there is plenty of time to get all this sort of stuff in order.

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6721
  • No sense of urgency.
    • outerra.com
Cartographers stuff
« Reply #46 on: May 31, 2011, 07:55:14 am »

Well yes, the snow tongues aren't so prominent, and it's true it can't be simulated accurately using just a locally operating math. External bias map would help covering these cases, while still keeping the look consistent with the underlying high frequency terrain details.

The thing is, we cannot just apply a mask that says snow, it needs to consider the generated detail, that wasn't present when simulating. So what we are trying to do is to get a reasonably well looking and believable terrain first, without using external simulated sources. Then we would use the output from a simulation to generate bias maps, enhancing the generated output and making it more physically correct.
Logged

Redrobes

  • Member
  • **
  • Posts: 73
    • http://www.viewingdale.com
Cartographers stuff
« Reply #47 on: June 16, 2011, 01:09:46 pm »

Redrobes

  • Member
  • **
  • Posts: 73
    • http://www.viewingdale.com
Re: Cartographers stuff
« Reply #48 on: September 21, 2011, 09:49:22 am »

Hi cameni, Can I ask you about this bit:
... a custom compiler into GLSL that gets us rid of some of the aspects of its poor design.
I was messing about with some GLSL and trying out some lite stuff and I remembered that you used a custom compiler for it. So what bits about the GLSL source language did you think were a problem that you wanted to fix with a custom generator ? I was toying with GLSL just to get my feet wet with it with a longer term view to implementing the main processing loop of my GTS in it. I believe all I need to do is lots of float texture manipulation but knowing why you found some issues might keep me out of a swamp somewhere down the line. Its very hard to find any float texture math examples in GLSL on the web. I don't think I need double float for it so in theory I could do it on my current card.

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6721
  • No sense of urgency.
    • outerra.com
Re: Cartographers stuff
« Reply #49 on: September 21, 2011, 10:50:10 am »

Well, there's a lot of tiny bits that make it an ugly language for me. For example, here's how we write shaders:
Code: [Select]
VERTEX_SHADER
void v_unit(
    in int vertex_id    : VERTEXID,
    out float4 opos     : POSITION,
)
{ ... }

FRAGMENT_SHADER
uint4 f_compress(
    float4 fragcoord : FRAGCOORD,
    uniform sampler2D image,
    uniform int mip = 0
    )
{ ... }

The same code in GLSL has to be split into two files, where each function is 'main', with global variables instead of the parameters, making the code more messy and less readable. Original GLSL didn't support #include (added now). In GLSL you have half-ambiguously blocks and structures, but struct cannot be used here and there. Block scope is weird. Const has an additional constraint that it can be constructed only from constant expressions, but it was so awkward that now the board allows to use it in functions in its C-like meaning. Boolean vector operators are not supported, you must use lessThan etc, but they forgot vector and/or/xor. And so on.
Then there's a lot of minor cosmetic stuff that still bothers me - vector types named as float2, int3, uint4, bool3 in DirectX or Nvidia's cg are here vec2, ivec3, uvec4, bvec3. And lots of other stuff ...

However, we wouldn't probably make the compiler just because of this. Initially we were using Nvidia's cg that is capable of compiling into various profiles, one of them glsl. Nvidia of course didn't make the profiles for ATI, and the glsl output was limited and buggy and the support miserable. So we were forced to either cross over to the glsl or to make a preprocessor. We already had some apparatus that took cg generated code and provided wrappers so that the shaders could be integrated effortlessly with the engine. Given that I have written several parsers and code generators in my life, I decided to make a cg-like compiler to glsl, that would also generate all the gluing code.

Nowadays we can just write a new shader, and immediately start using it with a single-line directive in the engine. The generator takes care of everything in between. We also enhanced the language constructs from the original cg syntax.
Logged
Pages: 1 2 3 [4]