Announcing Microsoft DirectX Raytracing • Hacker News Board

Re: Announcing Microsoft DirectX Raytracing

#231

Post by DoveBrown » Wed, Mar 21, 2018, 2:51 PM UTC

shmerl wrote: post #230

DoveBrown wrote: post #227

Earlier quoted context omitted.

I disagree with the characterisation that internal engines are less cross platform because of lock-in, the big publishers don't care about lock-in. It's not part of the calculus in deciding whether to support a platform or not. A port of a game is more than changing the low-level APIs used to control the hardware. It's the hardware of the platfrom the decides the complexity of producing the port. Linux is a special c…

I'm looking at publishers who do release Linux games using internal engines. Most of them use binary or source wrapping. Only a minority are implementing proper native rendering in those engines. And I bet it's based on cost considerations like I said above. How would you explain it otherwise? And I'm sure that cost plays a role when small market is evaluated. The higher is the cost, the less likely such publisher is…

I agree that cost is a consideration of doing the port. From my experience what renderering API is used at the bottom is a very small factor in that cost calculation.

I think where we disagree is that I don't think of the lower level API as being much of a lock in. The better graphic programmers I know have pretty extensive experience of the various flavors of DirectX and OpenGL. The general principles are the same and good programmers move between them easily.

Re: Announcing Microsoft DirectX Raytracing

#232

Post by shmerl » Wed, Mar 21, 2018, 3:08 PM UTC

DoveBrown wrote: post #231

shmerl wrote: post #230

Earlier quoted context omitted.

I'm looking at publishers who do release Linux games using internal engines. Most of them use binary or source wrapping. Only a minority are implementing proper native rendering in those engines. And I bet it's based on cost considerations like I said above. How would you explain it otherwise? And I'm sure that cost plays a role when small market is evaluated. The higher is the cost, the less likely such publisher is…

I agree that cost is a consideration of doing the port. From my experience what renderering API is used at the bottom is a very small factor in that cost calculation. I think where we disagree is that I don't think of the lower level API as being much of a lock in. The better graphic programmers I know have pretty extensive experience of the various flavors of DirectX and OpenGL. The general principles are the same a…

> I think where we disagree is that I don't think of the lower level API as being much of a lock in.

Lock-in here doesn't mean they have no technical means of implementing other graphics backends, it means that implementation is hard.

A lot of common middleware supports Linux just fine. It's graphics that's usually the biggest hurdle. People have expertise to address it, but it's still a tax to pay. And different distros support is a very minor thing in comparison.

If graphics is not the biggest issue, what is then in your opinion?

Re: Announcing Microsoft DirectX Raytracing

#233

Post by DoveBrown » Wed, Mar 21, 2018, 3:37 PM UTC

shmerl wrote: post #232

DoveBrown wrote: post #231

Earlier quoted context omitted.

I agree that cost is a consideration of doing the port. From my experience what renderering API is used at the bottom is a very small factor in that cost calculation. I think where we disagree is that I don't think of the lower level API as being much of a lock in. The better graphic programmers I know have pretty extensive experience of the various flavors of DirectX and OpenGL. The general principles are the same a…

> I think where we disagree is that I don't think of the lower level API as being much of a lock in. Lock-in here doesn't mean they have no technical means of implementing other graphics backends, it means that implementation is hard. A lot of common middleware supports Linux just fine. It's graphics that's usually the biggest hurdle. People have expertise to address it, but it's still a tax to pay. And different dis…

> If graphics is not the biggest issue, what is then in your opinion?

Graphics is the biggest issue, but the issue isn't at the API level. It's in the driver and hardware differences below that layer.

The "tax" as you call it, comes mostly from the hardware drivers leaking through the abstraction. Part of this is AAA game developers fault since they are attempting to use all the GPU with edge-case tricks to eke out more performance.

Re: Announcing Microsoft DirectX Raytracing

#234

Post by simooooo » Wed, Mar 21, 2018, 6:30 PM UTC

milesvp wrote: post #94

joosters wrote: post #26

https://www.youtube.com/watch?v=LXo0WdlELJk I'm pleased to see that the tech video includes spherical mirrors. As I understand it, all raytracing demos are obliged by universal law to include at least three reflective balls in any promotion of the technology. One day, someone will figure out a game where these super-shiny ball bearings are a critical part of the gameplay, and at that point, raytracing will finally ta…

My understanding is that rasterization really made portal hard to make. They had to jump through a bunch of hoops to make it all work. Meanwhile I understand that adding portals to raytrace quake was like an afternoon's exercise. I'm also annoyed that there's a map in overwatch where the corner mirrors don't actually reflect anything :P I think generally with many of the tricks that have come out of SIGGRAPH for the…

Hollywood first point? ;)

Re: Announcing Microsoft DirectX Raytracing

#235

Post by avhon1 » Mon, Mar 26, 2018, 3:07 AM UTC

oh_sigh wrote: post #15

bhouston wrote: post #13

Earlier quoted context omitted.

In path tracing ( https://en.wikipedia.org/wiki/Path_tracing ), which is what the VFX industry uses primarily, both directions happen.

Does anyone use path tracing for live renderings? I think that is the question.

Blender's path tracing engine, Cycles, supports realtime use in the editing viewport. Unless your machine is quite powerful, however, it doesn't render anywhere close to 30fps. Instead, it iteratively updates the viewport. It is fast enough that this is tolerable and useful for many workload+workstation combinations.