Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[thx_nb]

Hi all,

I'm curious, will the engine be able to handle land that's below sea level, but is not flooded (polders and such)? I live in the Netherlands, a significant part of which lies below sea level, but is protected by dikes and other measures.
In Outerra (Anteworld) that part of the Netherlands is currently just flooded, because only elevation data is used.

Will there be a solution for this type of situation in the future?

[PytonPago]

Hi all,

I'm curious, will the engine be able to handle land that's below sea level, but is not flooded (polders and such)? I live in the Netherlands, a significant part of which lies below sea level, but is protected by dikes and other measures.
In Outerra (Anteworld) that part of the Netherlands is currently just flooded, because only elevation data is used.

Will there be a solution for this type of situation in the future?

 I think, that comes whyte rivers and seas - had to be as an exceptional area from global water level ... may take some while.

[cameni]

Right, will come with the lakes - polygons that specify a custom water level, can push it up or down.

[ggraz]

I am also interested in this implementation; I am from another part of your Europe, which is below-sea-level
(in the 0,-10 feet range); and it looks like it was water-flooded by the engine.

In the attached screenshots, you can see a big river delta (top-right feature), affected by flooding,
and the other affected area (we are just 100 km south of Venice here); also, what is the white-ish stuff?
beach/sandstone procedurally generated?

As a side note, also in the screenshot: the engine behaves quite well under wine!

[giucam]

Interesting, it didn't work last time I tried! ggraz, what driver are you running? I'll try it again on my Intel HD 4000 as soon as i can.

[ggraz]

Interesting, it didn't work last time I tried! ggraz, what driver are you running? I'll try it again on my Intel HD 4000 as soon as i can.

I have wine-1.7.13 with a 32-bit prefix and a nvidia gts450 with blob driver 304.119 ; the output from the engine is

DEBUG: Windows version: 6.1.7601
DEBUG: CPU info:
        CPU string: GenuineIntel
        CPU brand string: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
        Stepping ID: 11
        Model: 15
        Family: 6
        Processor type: 0
        Extended model: 0
        Extended family: 0
        Brand Index: 0
        CLFLUSH cache line size: 64
        APIC Physical ID: 3
DEBUG: Reading C:\users\guido\Outerra\eng.cfg
DEBUG: GPU Vendor: NVIDIA Corporation
DEBUG: GL Renderer: GeForce GTS 450/PCIe/SSE2
DEBUG: GL Version: (420) 4.2.0 NVIDIA 304.119
DEBUG: OpenGL context defaults to: Nvidia
DEBUG: Display devices attached to desktop:
\\.\DISPLAY1                     0000 0000 X11 Windowing System
DEBUG: GPU System info
    Graphics card: X11 Windowing System
    GPU vendor ID: 10de (NVIDIA Corporation)
    GPU device ID: 0000
    OpenGL driver version:  (nvoglv32.dll)
    OpenGL driver build number: 0
DEBUG: Unable to find Nvidia driver version number. Please update you graphics card drivers, otherwise you can experience performance and stability issues.


The last DEBUG message I also get in a dialog box before the window opens, yet it seems to be no problem.

[giucam]

Mmh, so that's a different beast to what I have... I have only gl 3.3 core profile here, and 3.1 compatibility. Cameni, is that enough theoretically?

[cameni]

3.3 core should be enough, but I guess a lot will depend also on the quality of the drivers. Hm, but I think we are setting the compatibility profile now ... there was some problem with core on some drivers, even though we are using core for development.

[giucam]

Well, Mesa has an environment variable to override the advertised supported gl version, so i can make outerra think it can create a 3.3 compatibility profile i guess, and as long as it doesn't actually use any compatibility thing it should work™.