Print

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

[wledzian]

I've been following the growth of the Outerra engine for a while, and am thoroughly impressed.  I've got a deep interest in flight simulation, and am excited about the potential to eventually use this engine to provide my external visuals.   One glaring issue I've seen with just about every engine I've seen to date is that the visuals are generated via a planar (perspective) frustum, and thus are geometrically incapable of generating a single window in excess of 180°.  I've seen partial workarounds using multiple windows generated via independent frustums at different angles, but these still have an issue of angular mismatch at the edges.

There are software solutions available which will perform a post-render warp on these images to convert the perspective projections into cylindrical projections, but by their nature, the image cannot be quite perfect.  Other solutions have been to render a full cubemap at extended resolution and perform a post-render spherical sampling of the cubemap.  This approach would appear to place significant additional load on the rendering system, and still result in scaling artifacts.

My request:
Is it possible (read: 'are you willing') to include an additional step in the render pipeline to perform the proper image warp at the geometry level, pre-render?

My understanding (simplified) of the rasterizing pipeline (please forgive me if this is completely wrong)
1: Transform world geometry to camera-centered geometry
2: Perform a frustum cull to eliminate geometry that will not be visible
3: Scale culled (perspective) geometry to a 1x1x1 cube (or similar depending on OpenGL or DirectX)
4: Render scaled geometry to framebuffer

I am not familiar with the internal workings of the rendering pipeline, so please forgive my ignorance if this is more difficult than I imagine...

My proposal is that additional steps be performed as follows:
2a: Repeat as necessary with additional frustums to provide the requested total FOV
3a: For each scaled frustum, transform all points as appropriate to convert the perspective projection to a spherical or cylindrical projection.  Cull any points extending above or below the 1x1x1 cube.
3b: Place each re-transformed frustum side-by-side and re-scale to the 1x1x1 cube.

This should, in theory, produce a seamless single-window spherical or cylindrical projection without the artifacts that result from post-render warping and scaling of an image.

[cameni]

Yes, one possible solution is to render the world using several independent frustums that will be then reprojected into the framebuffer. To get rid of the scaling artifacts, you'd need extended resolution so that the stretched parts don't lose detail. The cubemap step isn't necessary with current hardware, the reprojection can be done in programmable shaders directly. There are still going to be some scaling artifacts because of uneven scaling and filtering kernel widths though.

What you are suggesting can be again done without the cube mapping, and even without the multiple frustums. With modern graphics cards you can use programmable shaders for any projection you need, so instead of a perspective output you can use something different or add a correction.
However, there's a catch. You can project the points (vertices) in any way you want, but fragments (pixels) between the vertices are still going to be interpolated perspectively. This means that if you output a long triangle, that would actually have curved edges in your projection, the hw rasterizer will still produce straight edges. Unfortunately, there's no hardware supporting custom rasterization yet.

Now this actually wouldn't be such a problem in Outerra terrain and environment rendering because here the tesselation of geometry is quite high. But it may be a problem for some models and close views.
One thing can help here are the tesselation shaders, that can refine the geometry dynamically, creating finer meshing and avoiding long edges in these critical cases.

[wledzian]

Wow, thanks for replying so quickly.

I had considered the issue with long straight edges still rasterizing as straight lines, however I figured that wouldn't be much of a problem as long as the geometry was finely tesselated.

You mention fragment shaders being capable of performing any projection I need.  I suppose this is where my understanding breaks down.  Are fragment shaders capable of generating single views in excess of 180°?

I feel a bit like a fifth grader asking how calculus works, as in I might be able to understand that an integral represents the area under the curve, but I'd be completely lost if you tried to tell me how to evaluate one.  from that standpoint, I'm not looking for a deep explanation.  My hope was that the above simplified rendering pipeline would illustrate that I've got at least a basic grasp of the issue, and that I'm not -just- pleading for a feature I know nothing about.

That said, I am pleading for a feature.

Being a flight simulator 'enthusiast', I'm in the process of building a flight simulator in my office.  Not satisfied with flat displays of any size, I designed a 220° collimated visual system, and with the help of a friend, built a functional prototype.  While we've got software to perform the image correction and edge-blending to project onto our screen, we're still dealing with issues related to the multi-frustum image generation we're forced to use.  I would be elated to be able to use a single seamless window across the entire display.



If this is a feature that you've given any consideration to including, consider this a big "Yes, Please!"

[cameni]

Wow, amazing piece of hardware.

There are several types of programmable shaders in the pipeline. The ones we are talking about are the vertex shaders, which usually input data (vertices) from model or world space, and transform it into screen space with a perspective component for interpolation. Here's where you'd plug in - suppose you have one long framebuffer that will be projected onto your curved screen. You know exactly where your every world-space point ends up on that plane, don't you? So that's what you do in the vertex shader, you use a custom equation to convert from world space to your screen space. In truth, there's always a custom code in the vertex shader, but usually it's a common perspective matrix multiplication.

Fragment shaders come last; the fragment shader is executed for each pixel that the rasterizer covers when filling a triangle on the screen. The triangle was defined by three screen-space points coming out from the vertex shader. There are other types of shaders but these aren't relevant here.

In order to support this we would need to add the projection code to every vertex shader that does world rendering in Outerra - there are several of them, for terrain, trees, models etc. But it's no problem, even now we have a custom code there for dealing with the huge depth ranges.

[C. Shawn Smith]

Don't mean to post off-topic, but that is one HELL of a piece of hardware.  I was originally going to say "HELL of a FRAKKING piece" because the guy sitting in the cockpit reminds me of Aaron Douglas (Chief Tyrol) from the Battlestar Galactica reboot.

Man, I'd die if I had something like this to play with, especially in Outerra.

[ZeosPantera]

I too someday hope to have a 360° view into the digital world. The hardware exists right now with a six out eyefinity and some cheap 50" televisions. The projector and seamless screen is a more desirable setup but brings with it a lot of issues for the software to cope with. With six flat planes you can just combine six separate camera views on one long rendered plane. The video processing power to do that with any sort of speed and quality is going to be legendary. In my perfect world, a simulator like the one you see above could really be considered three separate triple-head setups. Where the focus of primary attention can change to a different screen in front of a different set of physical control surfaces. IE..

When in a drivable ground vehicle a wheel and pedals in front of monitor 2 is primary while 1 and 3 act to create the sides and 4 5 6 are rear..

Then when entering an airplane, monitor 4 becomes primary and 3 and 5 act as the immediate side views making 6 1 2 rear..

On foot basic keyboard mouse controls on a flat surface in front of now primary monitor 6 with 5 and 1 to the immediate left and right and 2 3 4 behind.

All you need is a nice swivel chair and you get three cockpits in one!

[wledzian]

I've long heard the term 'vertex shader', but as I'm not a graphics guy, I continued to associate 'shader' with 'the bit that determines what color a pixel should be', fully distinct from 'the bit that determines where a vertex goes on-screen'.  Is it really as simple as using a cartesian-to-polar transform instead of a cartesian-to-perspective transform?

Are you saying that you may be willing to incorporate this feature? If so, is there any chance I could get in on the beta?

If you are willing to incorporate this, my ideal implementation would allow a user-specified horizontal and vertical FOV independent of display resolution and aspect ratio.

Thanks!

[cameni]

Yes, what was once a fixed pipeline is now fully programmable one (well, except for the rasterizer). So the graphics API expects that vertex shader tells it where the point will lie on the screen, and it's upon you how do you compute it. However, as I said - the rasterizer is fixed and operates in linear space and expects homogenous coordinates for correct perspective interpolation. Perspective interpolation isn't a problem here, but the linear space requires a fine tesselation so that piecewise approximation works.

We are willing to incorporate it. We are going to provide support for multiple monitors, and this can be solved together with it. It will take some time though, no need to jump on beta as we first want to release a public demo of the existing stuff. Then (or together with it) we are going to announce our demo game built on Outerra, that could be also preordered, with early adopters getting regular beta builds with functionality added as we implement it.

Now, the game itself is likely of no interest to you, but what we plan there is a special sim-connect mode, that will make it possible to use Outerra as an image generator for existing simulators (probably FS* and X-plane, but we'll have to look at the details and possibilities). What we want to achieve with this, is to give simmers the possibility to taste and enjoy the tech, while still being able to use the rest of their systems normally.

I'm not sure if the integration can be made as effective as with the existing JSBSim FDM we use, specifically whether we can feed back the collision data of our world, since the detail is augmented by fractals and the base meshes are likely to be slightly different as well. It needs some digging in manuals and APIs.

[Jagerbomber]

[ZeosPantera]

Ultimate Battlefield 3 Simulator - Build & Test (Full Video) - The Gadget Show

I have seen this and gagged. And not the good gag.. All that hardware used to about 8% of it's potential.

Here is the short list of what fails in this video.

• The image on screen rotates around with the user in a 360° usable environment. North in game should be fixed to north IRL
• The FOV is obviously all wrong.
• The in-game gun should no longer be visible since it is in the user's hand
• They used battlefield 3

[Jagerbomber]

Oh QQ more.  BF3's max Field of View setting is 90 and you aren't allowed to remove your hands and gun from view anyways.  They did what they could with the limitations they had to work with.

Also, really?... You're complaining about North in the game not being linked to North in real life in this setup?... Really?

[ZeosPantera]

Defending the use of BF3

Point being..... If someone has a $100,000 simulator platform they could at least load up a real simulator environment and in about 20 minutes remove the weapon, fix the rotating view and adjust the FOV to match perfectly.

Just because something is popular doesn't make it the right choice. Would that video have the same number of views if it were ArmA on there? Maybe not. But then again the news wouldn't have visited them if it were arma.

[Jagerbomber]

Implying that ArmA is immersive at all

[wledzian]

Cameni, that's music to my ears.

If presented with a beta with a SimConnect link to FSX, I would be more than willing to report back on mesh similarity (were I to beg any more obviously, I'd probably have to get down on my knees...) 

Heck - do you have an SDK I can look at?  This might be just the drive I need to learn to program my own SimConnect apps...

[wledzian]

Kicking an old thread - but hey, at least it's my own thread, and the kick is related.

Wow, it's been a while since my original request for native vertex-based spherical projection.  I've been keeping an eye on things, but not particularly frequently, as my collimated display has been sitting mostly unused gathering dust for the past four years.  Guess that's to be expected with three kids under five.  Anyway, I'm finally spending some time trying to get it dusted off and running, and I took another look at the progress in Outerra.  It's looking amazing, but I'm still hoping for a usable arbitrarily-wide spherical projection at some point.  For now, I see the following issues, illustrated in the linked video:

https://www.youtube.com/watch?v=9oJOBWUAVE0&feature=youtu.be

- Tree shadows detached from the trees except directly in the center of the view
- Large-scale terrain lighting shifts with the view
- Trees that I'm passing well above seem to grow up directly into my path as I pass over them. (maybe a result of correct vertex warping, but large-polygon perspective?)

Any chance that these issues will be corrected?

In addition to that, I notice that we're still limited to 179.9°, as though it is being generated via a single frustum, although warped at the vertex level.

I wonder if my original request has created an inappropriate amount of added work; with the increase in rendering horsepower over the past four years, it is becoming less distasteful to simply render multiple views at a higher resolution and resample them to a spherical projection.  Could this be a short-term option to permit fields of view beyond 180°?  When (if?) you do introduce beyond-180° rendering by whatever means you deem appropriate, could you PLEASE allow for horizontal and vertical fields of view that are not tied to each other?  For instance, I'd like to be able to specify 220° horizontal by 40° vertical, regardless of the actual aspect ratio of my displays.

Again, thanks for your amazing work!