[Official] Technical Engine Development faq / blog
Moderator: Moderators for English X Forum
Heh. The Linux version is in absolutely great condition already Wasn't expecting this at all because of the warnings and Alpha status. Great work!
I need to learn a proper way to inform about the problems.
I need to learn a proper way to inform about the problems.
Last edited by edqe on Thu, 12. Mar 15, 20:27, edited 4 times in total.
Support thread. - http://forum.egosoft.com/viewtopic.php? ... 33#4504833edqe wrote:I need to learn a proper way to inform about the problems.
Can I run the Linux version on Windows?
Actual question, I do not have a powerful enough PC right now to try it out but it says that you can select the Linux branch in Steam...
Actual question, I do not have a powerful enough PC right now to try it out but it says that you can select the Linux branch in Steam...
Code: Select all
Und wenn ein Forenbösewicht, was Ungezogenes spricht, dann hol' ich meinen Kaktus und der sticht sticht sticht.
/l、
゙(゚、 。 7
l、゙ ~ヽ /
じしf_, )ノ
Oh, thanks a lot - I thought there is some bug tracker/bugzilla somewhere.Terre wrote:Support thread. - http://forum.egosoft.com/viewtopic.php? ... 33#4504833edqe wrote:I need to learn a proper way to inform about the problems.
- BigBANGtheory
- Posts: 3168
- Joined: Sun, 23. Oct 05, 12:13
I think many of us enjoyed the DevBlog videos prior to XR's release, totally worth doing again when the time comes.CBJ wrote:I rather doubt this would be a viable proposition for us, but we do occasionally produce "DevBlog"-type videos that might cover some of this ground.xenoncore123 wrote:5) Would you consider doing some youtube tutorials on how you 3D model, Animate texture, Program, and sound/music creation because you do some beautiful scenery and Space 3D models and animation such as the new Xenon ships and the animation on the Stations and the programming of the economic system. By doing this you could make a ton of money from advertising the content and then spending that money on "office things" if you wish.
@tomtalk24
Well in short: yes, yes, yes, and yes;)
The longer answer is that of course you can never be sure until you try, also how much benefit you'd see depends on the hardware. But based on what I've seen and intuition I can guestimate this:
We'd benefit from just a straight drop-in equivalent to the opengl implementation, especially on amd drivers (both on linux and windows). Although it probably would require a bit more intelligent behaviour from us (currently the drivers do many tricks like buffer orphaning so we don't have to).
There're many improvements that vulkan would enable, ranging from relatively simple related to streaming, to complete redesigns of the renderer and shifting more work from the world-move to it.
We do take the steam hardware survey into account when making decisions about what we consider to be necessary to support (or at least I do;p). This is purely a balancing question, how much benefit for whom vs how many legacy systems are incompatible vs how much development effort.
The universal answer is we're willing to sacrifice some, we won't sacrifice much, but unfortunately dev-time is usually the largest constraint.
So frankly the most likely implementation is side-by-side with opengl so we could ship two binaries, at least for a while.
Well in short: yes, yes, yes, and yes;)
The longer answer is that of course you can never be sure until you try, also how much benefit you'd see depends on the hardware. But based on what I've seen and intuition I can guestimate this:
We'd benefit from just a straight drop-in equivalent to the opengl implementation, especially on amd drivers (both on linux and windows). Although it probably would require a bit more intelligent behaviour from us (currently the drivers do many tricks like buffer orphaning so we don't have to).
There're many improvements that vulkan would enable, ranging from relatively simple related to streaming, to complete redesigns of the renderer and shifting more work from the world-move to it.
We do take the steam hardware survey into account when making decisions about what we consider to be necessary to support (or at least I do;p). This is purely a balancing question, how much benefit for whom vs how many legacy systems are incompatible vs how much development effort.
The universal answer is we're willing to sacrifice some, we won't sacrifice much, but unfortunately dev-time is usually the largest constraint.
So frankly the most likely implementation is side-by-side with opengl so we could ship two binaries, at least for a while.
Because our game is somewhat unusual and models the entire game universe rather than just the part the player is in, we start with "gamegraph culling" which excludes objects that are not in a part of the galaxy that is visible to the player. Next we do frustum culling, which uses two frustums, one for the camera and one for the primary light source (usually the sun) so that shadows can be correctly handled. At this point we also do LOD culling, which ensures that objects that are too far away and/or too small to be rendered get ignored. All of these are hierarchical, so that if we cull an object, we also cull all the smaller things attached to that object. All of these happen early on during the CPU part of the rendering process.
Later on we use pretty standard methods of depth-based per-pixel occlusion culling and backface culling, most of which happens on the GPU. These are helped by making some sensible choices beforehand, for example processing the cockpit interior geometry first so that anything hidden by that will quickly be culled.
Later on we use pretty standard methods of depth-based per-pixel occlusion culling and backface culling, most of which happens on the GPU. These are helped by making some sensible choices beforehand, for example processing the cockpit interior geometry first so that anything hidden by that will quickly be culled.
thanks for quick answer. when on station, are you using portal culling? i mean rendering only roomblocks (like the room you are in and the neighbouring rooms) or the entire station and the invisible bits getting culled on the gpu?
which per-pixel methods do you use? you say "most of which happens on the GPU". does it mean you use occlusion queries?
which per-pixel methods do you use? you say "most of which happens on the GPU". does it mean you use occlusion queries?
Well - judging by the funny bug that used to occur back in 1.x-2.0 if I recall - you would just glide off the ship through the walls of the station once you dock. When that happened - you could actually see the whole station.bambikaka wrote:thanks for quick answer. when on station, are you using portal culling? i mean rendering only roomblocks (like the room you are in and the neighbouring rooms) or the entire station and the invisible bits getting culled on the gpu?
which per-pixel methods do you use? you say "most of which happens on the GPU". does it mean you use occlusion queries?
That might got changed later though
(Question is "mostly" headed at the rendering part of your engine but not exclusively)
Do you keep developing your engine and if yes, has it developed further already then what we can see in XR right now or was the engine developing hand in hand with XR and now your new upcoming game?
May I ask what your "technical" plans for the future are? What do you want to have implemented or need to have implemented for your next game?
I am pointing in the direction of books like GPU gems from NVidida or other game studios often publish articles about different techniques they implemented, as well.
Your engine for example can't render station interiors very well: small, large frametime and lack of windows for obvious reasons.
Do you keep developing your engine and if yes, has it developed further already then what we can see in XR right now or was the engine developing hand in hand with XR and now your new upcoming game?
May I ask what your "technical" plans for the future are? What do you want to have implemented or need to have implemented for your next game?
I am pointing in the direction of books like GPU gems from NVidida or other game studios often publish articles about different techniques they implemented, as well.
Your engine for example can't render station interiors very well: small, large frametime and lack of windows for obvious reasons.
Spami
Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.
- Albert Einstein
Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.
- Albert Einstein
really? never encountered that. now thats a serious concern-Skipp- wrote:Well - judging by the funny bug that used to occur back in 1.x-2.0 if I recall - you would just glide off the ship through the walls of the station once you dock. When that happened - you could actually see the whole station.bambikaka wrote:thanks for quick answer. when on station, are you using portal culling? i mean rendering only roomblocks (like the room you are in and the neighbouring rooms) or the entire station and the invisible bits getting culled on the gpu?
which per-pixel methods do you use? you say "most of which happens on the GPU". does it mean you use occlusion queries?
That might got changed later though
Re: [Official] Technical Engine Development faq / blog
Hello everyone,
Question is:
Is X:Rebirth written on OpenGL?
wanna do "injectSMAA" (or similar soft) but that stuff is for d3d games
Any recommendations on how to enable SMAA in X:R (native FXAA is too blurry)?
Question is:
Is X:Rebirth written on OpenGL?
wanna do "injectSMAA" (or similar soft) but that stuff is for d3d games
Any recommendations on how to enable SMAA in X:R (native FXAA is too blurry)?
Re: [Official] Technical Engine Development faq / blog
Done. Used ReShade
Re: [Official] Technical Engine Development faq / blog
Thank's a lot, 'cause I was tweaking OpenGL version of shaders for few days and started to get suspicious why there is no gui (from RS not game itself)!
...On Win7...