• Hey Guest. Check out your NeoGAF Wrapped 2025 results here!

Cerny patent on Geometry engine details

geordiemp

Member
So,



Put link in quote as it seems to be on a loading loop. I would upload some images but uploading for me does not work so....

Patent goes into great detail on pixel densities and changing FOV and removing rendering inefficiencies up to 2.5 x (Page 4) and high FOV applications. People seem to like that 2.5 number ...

It could be a Geometry engine that is optimised heavily for VR as well as very fast culling..

Not got time to read it in full, but it looks like Geomtry engine is likely highly customised, and quickly scanning it would not be surprising if Ps5 skips the VRS as the pixel density discussion is in the patent.

Hopefully posters can read and discuss this patent, likely on ps5, and remain civil.
 
Last edited:
Yes it does, there is allot going on here for sure, I will read it tonight, there is allot here. That tweet my Matt Harget suggesting Geometry engine over VRS teased but was vague.



"Doesn't hold a handle to Geometry engine" - shots fired, call the mambulance!

geordiemp geordiemp let US know your findings and Insights pleased, I don't understand this...
 
Last edited:
This needs thorough explanation and a Teardown Session by Marky Mark...
Don't worry I'm pretty sure we're like 20 posts away from this thread having explained this in detail and everybody understanding it / being able to judge the potential.
To me it reads a lot like VRS; might actually read through this; I love trying to understand that kind of stuff.

Also I now learned that he is called Mark Evan Cerny which makes for way better Anagrams.

very crank mane
cream rank envy
very crank name
 
Last edited:
So it's custom after all, not stock rdna2. You don't do this without intent. Could be that RDNA3 part previously alluded to.
There's no way to guess which custom bits from either console will make it to the RDNA roadmap in the future.

This could get really exciting, soon!


Don't worry I'm pretty sure we're like 20 posts away from this thread having explained this in detail and everybody understanding it / being able to judge the potential.
To me it reads a lot like VRS; might actually read through this; I love trying to understand that kind of stuff.

Also I now learned that he is called Mark Evan Cerny which makes for way better Anagrams.

very crank mane
cream rank envy
very crank name

I will for sure keep looking and waiting for the SSD (secret sauce deluxe) explanation!
 
Last edited:
So if I am getting this right, if you have something like a sphere for example and you are getting close to it. The surface which is close to you wil have more vertices than the surface further from you, I mean on the curves which are at the FOV further from you? Like LOD for object, but gradual?
 
Last edited:
Yes it does, there is allot going on here for sure, I will read it tonight, there is allot here. That tweet my Matt Harget suggesting Geometry engine over VRS teased but was vague.


Isn't DX12 Mesh shaders not the same or very similar to the Geometry engine?

So you would/could have Mesh Shader + VRS At the same time.

edit: spelling
 
Last edited:
Isn't DX12 Mesh shaders not the same or very similar to the Geometry engine?

So you would/could have Mesh Shader + VRS At the same time.

edit: spelling

Well if it was the same as mesh shaders there would not be such a large patent, but it will take time to digest. As Sony are into VR, it is not surprising they have different needs. How it relates to mesh shaders nobody knows for now.

At least we put to bed its not RDNA 1.1 :messenger_beaming:
 
Last edited:
So if I am getting this right, if you something like a sphere for example and you are going close to it. The surface which is close to you wil have more vertices than the surface further from you, I mean on the curves which are at the FOV further from you? Like LOD for object, but gradual?

You mean like the Technique from Horizon Zero Dawn a little bit? Calculating only what we are seeing? Just in this form rather a gradual version that is preferring closer objects and limiting further away objects?
 
You mean like the Technique from Horizon Zero Dawn a little bit? Calculating only what we are seeing? Just in this form rather a gradual version that is preferring closer objects and limiting further away objects?
No no that Occlusion/Frustrum Culling, that's technique which was presented on Horizon, but basically every game has it. Because otherwise they would run like shit.

This what I read from the document is basicaly all about just geometry, if you have the object and it's big, you have to have only the part which is close to you detailed, the parts which is further from you can be simplified. Something like tessellation, but gradual on single object.

If I am getting this right.
 
So it's custom after all, not stock rdna2. You don't do this without intent. Could be that RDNA3 part previously alluded to.

Its funny in Cernys road to Ps5 he did say brand new Geomtry engine for Ps5, but as Geometry engine is standard naming from AMD, everybody just ignored that part of his speach.
 
Its funny in Cernys road to Ps5 he did say brand new Geomtry engine for Ps5, but as Geometry engine is standard naming from AMD, everybody just ignored that part of his speach.
Yeah well it could have better name tho, I though it was the same. Because name matter.
 
Isn't DX12 Mesh shaders not the same or very similar to the Geometry engine?

So you would/could have Mesh Shader + VRS At the same time.

edit: spelling

yeah, vrs and primitive/mesh (not saying that they are the same thing because they are not) shaders can be combined.
 
Yeah well it could have better name tho, I though it was the same. Because name matter.

Oh you can imagine what some marketing departments would do with this, 2.5 efficiency videos, The super tesselation engine lol

We need another Cerny classroom.
 
Last edited:
Oh you can imagine what some marketing departments would do with this, 2.5 efficiency videos lol, The super tesselation engine lol
Super Tesselation Engine sounds cool tho. STE, that's some car performance badge, no? Seems appropriate, if it's going to work as advertised.
 
The answer was stareing us in the face the whole time. I bet if Cerny had called it their 'acceleratron' or something people would have been all over it. But as Cerny is an engineer and not a marketeer he just calls it what it is, a geometry engine, it just happens to be an advanced one.

STE sounds better than my attempt! 😂
 
Last edited:
So, just before primitive assembly in the pipeline, they use a discrete space partitioning based on the frustum that symetrically (but not uniformly) discretizes the space into zones and those zones are given priority with how many vertices are allowed to be put in there for a given primitive and zones with less distance to the FoVs center are given higher priority? Does this algorithm preserve shape silhouettes? Because that sounds to me like the problem with regards to progressive meshes/progressive LODs (usually, LODs are still being swapped via some sort of blending technique or predetermined edge collapses/expansions defined by the modeller/designer and saved as an addition in the index face set of a mesh), which is still being researched afaik (There is some progress with CNNs in that regard but nothing good when it comes to analytical solutions).
 
So, just before primitive assembly in the pipeline, they use a discrete space partitioning based on the frustum that symetrically (but not uniformly) discretizes the space into zones and those zones are given priority with how many vertices are allowed to be put in there for a given primitive and zones with less distance to the FoVs center are given higher priority? Does this algorithm preserve shape silhouettes? Because that sounds to me like the problem with regards to progressive meshes/progressive LODs (usually, LODs are still being swapped via some sort of blending technique or predetermined edge collapses/expansions defined by the modeller/designer and saved as an addition in the index face set of a mesh), which is still being researched afaik (There is some progress with CNNs in that regard but nothing good when it comes to analytical solutions).

What do you make of the rendering efficiency details on page 4.
 
So, just before primitive assembly in the pipeline, they use a discrete space partitioning based on the frustum that symetrically (but not uniformly) discretizes the space into zones and those zones are given priority with how many vertices are allowed to be put in there for a given primitive and zones with less distance to the FoVs center are given higher priority? Does this algorithm preserve shape silhouettes? Because that sounds to me like the problem with regards to progressive meshes/progressive LODs (usually, LODs are still being swapped via some sort of blending technique or predetermined edge collapses/expansions defined by the modeller/designer and saved as an addition in the index face set of a mesh), which is still being researched afaik (There is some progress with CNNs in that regard but nothing good when it comes to analytical solutions).

Is this some new form of chinese dialect?
 
So, just before primitive assembly in the pipeline, they use a discrete space partitioning based on the frustum that symetrically (but not uniformly) discretizes the space into zones and those zones are given priority with how many vertices are allowed to be put in there for a given primitive and zones with less distance to the FoVs center are given higher priority? Does this algorithm preserve shape silhouettes? Because that sounds to me like the problem with regards to progressive meshes/progressive LODs (usually, LODs are still being swapped via some sort of blending technique or predetermined edge collapses/expansions defined by the modeller/designer and saved as an addition in the index face set of a mesh), which is still being researched afaik (There is some progress with CNNs in that regard but nothing good when it comes to analytical solutions).
Eddie-Murphy-Is-Not-Sure-About-His-Approval-Head-Nod.gif
 
What do you make of the rendering efficiency details on page 4.
So, now after skimming again through the text, they're also calling separately parameterized vertex shaders for each zone. So that's where the comparison to VRS comes from, I guess. So VRS is just partitioning the screen space into regular grids (given by the programmer), right? Whereas the approach here is to have also a partitioning of space but done earlier (using the frustum, so long before vertex shaders are invoked) and each zone is parameterized and can be irregular (but symmetrical) and also takes vertex processing into account, so actual geometry. So in essence two different approaches to the same problem, so to speak, only VRS is much simpler to reason about, IMHO (and therefore simpler to optimize for). And the conditional partial reduction of vertices can be done with geometry shaders but I guess with more overhead? (I would need to think about this more)
But I suspect that it comes down to specifics of games. I don't think that one approach is "generally better" than the other. But it seems to me that the Geometry Engine-thingy is done with VR in mind, hence why they chose the frustum and FoV as their basis. The big thing that springs to mind is that the Geometry Engine approach might work better with foveated rendering (basically giving a sharper image/more detail to the part of the screen where you are focussing on with your eyes, which requires an eye-tracker in your HMD).

But I'd be careful to pass final judgment on the performance gains of each method for now. I'd love to see what happens when you've got a lot of effects going on that work off of vertex shaders. At worst, the performance should converge to the performance of the "old methods", right? But there's a feeling that this might not be the case and could result in worse performance in those (very specific) kinds of situations. But I've been wrong before (countless times, lol). But interesting developments indeed.

Is this some new form of chinese dialect?
I had 3 cups of coffee, lol.
 
Yes it does, there is allot going on here for sure, I will read it tonight, there is allot here. That tweet my Matt Harget suggesting Geometry engine over VRS teased but was vague.


So the reason PS5 won't have VRS is because the Geometry Engine with primitive shaders is the better solution to save on memory budgets just like we thought.

Next generation will be so interesting
 
Sounds great, but wheres the games that are mind blowing using it?

It takes time and resources for developers to use all of this. Hellblade 2 for instance was said to be very early in development, likely not coming out until 2022 or beyond. Sony didn't show any first party games that are that far out from releasing.
 
It takes time and resources for developers to use all of this. Hellblade 2 for instance was said to be very early in development, likely not coming out until 2022 or beyond. Sony didn't show any first party games that are that far out from releasing.
Didn't they also recently announce that they'd change to Unreal Engine 5 for Hellblade 2? Or was it announced using Unreal 5 from the beginning? I don't quite remember, lol. I just remember reading something about Unreal Engine 5 and Hellblade 2.
 
Last edited:
Yes it does, there is allot going on here for sure, I will read it tonight, there is allot here. That tweet my Matt Harget suggesting Geometry engine over VRS teased but was vague.



This guy reminds me of greenberg, always responding to any positive talking point about the competitor with downplaying like a child.
 
It takes time and resources for developers to use all of this. Hellblade 2 for instance was said to be very early in development, likely not coming out until 2022 or beyond. Sony didn't show any first party games that are that far out from releasing.

Cerny was quite adamant he wanted features that imporved efficiency that did not take allot of work to us in his time to triangle. If the Geometry engine does this improvement automatically in hardware then ?
 
Last edited:
This guy reminds me of greenberg, always responding to any positive talking point about the competitor with downplaying like a child.

Behave, discuss the point rather than attack the messenger, Matt was just excited about Geometry engine, now we know why he was excited, put it into context.

I guess it did not take long
 
Last edited:
So after the SSD and RDNA fiasco THIS will finally put the nail in the coffin of the series x being more powerful.
 
Didn't they also recently announce that they'd change to Unreal Engine 5 for Hellblade 2? Or was it announced using Unreal 5 from the beginning? I don't quite remember, lol. I just remember reading something about Unreal Engine 5 and Hellblade 2.
Didn't Epic say that games on UE4 can easily be transported onto UE5 when it's final?
So it won't matter if they already develop on UE4, they can easily continue on UE5.
 
So, now after skimming again through the text, they're also calling separately parameterized vertex shaders for each zone. So that's where the comparison to VRS comes from, I guess. So VRS is just partitioning the screen space into regular grids (given by the programmer), right? Whereas the approach here is to have also a partitioning of space but done earlier (using the frustum, so long before vertex shaders are invoked) and each zone is parameterized and can be irregular (but symmetrical) and also takes vertex processing into account, so actual geometry. So in essence two different approaches to the same problem, so to speak, only VRS is much simpler to reason about, IMHO (and therefore simpler to optimize for). And the conditional partial reduction of vertices can be done with geometry shaders but I guess with more overhead? (I would need to think about this more)
But I suspect that it comes down to specifics of games. I don't think that one approach is "generally better" than the other. But it seems to me that the Geometry Engine-thingy is done with VR in mind, hence why they chose the frustum and FoV as their basis. The big thing that springs to mind is that the Geometry Engine approach might work better with foveated rendering (basically giving a sharper image/more detail to the part of the screen where you are focussing on with your eyes, which requires an eye-tracker in your HMD).

But I'd be careful to pass final judgment on the performance gains of each method for now. I'd love to see what happens when you've got a lot of effects going on that work off of vertex shaders. At worst, the performance should converge to the performance of the "old methods", right? But there's a feeling that this might not be the case and could result in worse performance in those (very specific) kinds of situations. But I've been wrong before (countless times, lol). But interesting developments indeed.


I had 3 cups of coffee, lol.
I also think the patent is mostly related to VR. Without "gaze tracker" mentioned in it (so the rumoured sensor in PSVR2 and that rumour comes from that patent, I guess) you'll end up with blurred image on a flat display because you can't assume that the player is sitting exactly in the middle and that nobody else is watching the screen from a side.

I once had an interesting article for translation which described a study on human perception in various areas of our FOV. Generally speaking, we perceive a lot more things in the lower half of it but it also depends on the colour (or rather contrast of the object against the background), size, if it moves, how it moves and how quickly it happens. There are a lot of dependencies which are a result of evolution (we are a hunter species, after all). The images in the patent show FOV divided almost exactly like I remember from the article. If they get it right, VR might get a lot better than it is now, elevating it from a gimmick to a groundbreaking experience in gaming. VR games won't have to look worse than "normal" games anymore because the actual FOV will be much smaller with the rest being rendered at much lower quality but you won't notice it due to how our eyes work (and how brain interprets their vision, most of all).
 
Last edited:
Didn't Epic say that games on UE4 can easily be transported onto UE5 when it's final?
So it won't matter if they already develop on UE4, they can easily continue on UE5.
Yeah, they did say that. I hope that's true, lol. Usually, when someone says "And you can easily move on from your current technological base to the next version!" it comes with a lot of "terms and conditions", so to speak. But I haven't worked with UE5 (yet), so maybe they solved this quite nicely. On that note, I am still sad that Valve don't seem to give a fuck about releasing Source 2 to the public. Source was really dope...
 
So,




Put link in quote as it seems to be on a loading loop. I would upload some images but uploading for me does not work so....

Patent goes into great detail on pixel densities and changing FOV and removing rendering inefficiencies up to 2.5 x (Page 4) and high FOV applications. People seem to like that 2.5 number ...

It could be a Geometry engine that is optimised heavily for VR as well as very fast culling..

Not got time to read it in full, but it looks like Geomtry engine is likely highly customised, and quickly scanning it would not be surprising if Ps5 skips the VRS as the pixel density discussion is in the patent.

Hopefully posters can read and discuss this patent, likely on ps5, and remain civil.

As many people suspected, more than meets the eye in regards to the ps5 architecture. Looking forward to the tech-heads discussing this, i will grab my pompoms
 
So,




Put link in quote as it seems to be on a loading loop. I would upload some images but uploading for me does not work so....

Patent goes into great detail on pixel densities and changing FOV and removing rendering inefficiencies up to 2.5 x (Page 4) and high FOV applications. People seem to like that 2.5 number ...

It could be a Geometry engine that is optimised heavily for VR as well as very fast culling..

Not got time to read it in full, but it looks like Geomtry engine is likely highly customised, and quickly scanning it would not be surprising if Ps5 skips the VRS as the pixel density discussion is in the patent.

Hopefully posters can read and discuss this patent, likely on ps5, and remain civil.

This patent clearly aims towards increasing efficiency for rendering frames for head mounted displays.
 
This patent clearly aims towards increasing efficiency for rendering frames for head mounted displays.

Its about projecting vertices onto a curved viewport and efficiency in rendering them, and clearly the basis of the new Ps5 Geometry engine that is a custom design, so not just VR.
 
Last edited:
Yes it does, there is allot going on here for sure, I will read it tonight, there is allot here. That tweet my Matt Harget suggesting Geometry engine over VRS teased but was vague.



But that's what Mesh Shading if for, no? I have a strange feeling both Sony and MS solutions are basically the exact same thing, but for unknown reasons they decided to name it differently... But yeah, the patent strongly suggest VR support, like that variable resolution tech where it's denser on the center and lower on the outer boarders, except the patent will apply to the geometry.
 
I also think the patent is mostly related to VR. Without "gaze tracker" mentioned in it (so the rumoured sensor in PSVR2 and that rumour comes from that patent, I guess) you'll end up with blurred image on a flat display because you can't assume that the player is sitting exactly in the middle and that nobody else is watching the screen from a side.

I once had an interesting article for translation which described a study on human perception in various areas of our FOV. Generally speaking, we perceive a lot more things in the lower half of it but it also depends on the colour (or rather contrast of the object against the background), size, if it moves, how it moves and how quickly it happens. There are a lot of dependencies which are a result of evolution (we are a hunter species, after all). The images in the patent show FOV divided almost exactly like I remember from the article. If they get it right, VR might get a lot better than it is now, elevating it from a gimmick to a groundbreaking experience in gaming. VR games won't have to look worse than "normal" games anymore because the actual FOV will be much smaller with the rest being rendered at much lower quality but you won't notice it due to how our eyes work (and how brain interprets their vision, most of all).
That's pretty interesting. Do you happen to know/remember whether there was one factor out of those (moving, contrast, upper/lower half of FoV) that had significantly more impact than the others?. Or to put it more formally, is there a variable with a lot of entropy? But yeah, it seems that Sony might have indeed developed it with VR in mind.
 
So, now after skimming again through the text, they're also calling separately parameterized vertex shaders for each zone. So that's where the comparison to VRS comes from, I guess. So VRS is just partitioning the screen space into regular grids (given by the programmer), right? Whereas the approach here is to have also a partitioning of space but done earlier (using the frustum, so long before vertex shaders are invoked) and each zone is parameterized and can be irregular (but symmetrical) and also takes vertex processing into account, so actual geometry. So in essence two different approaches to the same problem, so to speak, only VRS is much simpler to reason about, IMHO (and therefore simpler to optimize for). And the conditional partial reduction of vertices can be done with geometry shaders but I guess with more overhead? (I would need to think about this more)
But I suspect that it comes down to specifics of games. I don't think that one approach is "generally better" than the other. But it seems to me that the Geometry Engine-thingy is done with VR in mind, hence why they chose the frustum and FoV as their basis. The big thing that springs to mind is that the Geometry Engine approach might work better with foveated rendering (basically giving a sharper image/more detail to the part of the screen where you are focussing on with your eyes, which requires an eye-tracker in your HMD).

But I'd be careful to pass final judgment on the performance gains of each method for now. I'd love to see what happens when you've got a lot of effects going on that work off of vertex shaders. At worst, the performance should converge to the performance of the "old methods", right? But there's a feeling that this might not be the case and could result in worse performance in those (very specific) kinds of situations. But I've been wrong before (countless times, lol). But interesting developments indeed.
I'm not a coder, but it does read like foveated rendering for VR. The numerous mentions of eye focus, as well as the explicit reference to foveated rendering in paragraph 45, gives me the impression that this is a means of allowing improved geometry detail at the focal point in VR games. Some kind of dynamic tesselation taking place outside of that focal point, to cut down on what needs to be computed/rendered to allow maximum detail where it matters. Probably a remedial read of the patent, and probably something all VR engines strive to achieve anyway. But does this mean that there will be eye-tracking in the VR headset? I don't have one, so I don't know how common that is.

My initial read of the abstract was just that it was some fancy LOD blending based on distance from the viewer, but this seems more focused where the viewer/camera is focused. I assume the vertex weighting of the partitions are adjusted based on that. I can read the patent, but as I don't understand how it all works with actually converting 3D to 2D display, much of it escapes me. I find your posts helpful in distilling it, but I'm also not certain how well you're interpreting it. Certainly better than me, though.
 
I also think the patent is mostly related to VR. Without "gaze tracker" mentioned in it (so the rumoured sensor in PSVR2 and that rumour comes from that patent, I guess) you'll end up with blurred image on a flat display because you can't assume that the player is sitting exactly in the middle and that nobody else is watching the screen from a side.

I once had an interesting article for translation which described a study on human perception in various areas of our FOV. Generally speaking, we perceive a lot more things in the lower half of it but it also depends on the colour (or rather contrast of the object against the background), size, if it moves, how it moves and how quickly it happens. There are a lot of dependencies which are a result of evolution (we are a hunter species, after all). The images in the patent show FOV divided almost exactly like I remember from the article. If they get it right, VR might get a lot better than it is now, elevating it from a gimmick to a groundbreaking experience in gaming. VR games won't have to look worse than "normal" games anymore because the actual FOV will be much smaller with the rest being rendered at much lower quality but you won't notice it due to how our eyes work (and how brain interprets their vision, most of all).

There is a seperate patent on Foveated rendering and VRS effect from Cerny.
 
That's pretty interesting. Do you happen to know/remember whether there was one factor out of those (moving, contrast, upper/lower half of FoV) that had significantly more impact than the others?. Or to put it more formally, is there a variable with a lot of entropy? But yeah, it seems that Sony might have indeed developed it with VR in mind.
I found the title and after that a copy on the webs. Take a look.

Edit: I think it's not the whole text. The original publication is locked behind a paywall :/
 
Last edited:
I also think the patent is mostly related to VR. Without "gaze tracker" mentioned in it (so the rumoured sensor in PSVR2 and that rumour comes from that patent, I guess) you'll end up with blurred image on a flat display because you can't assume that the player is sitting exactly in the middle and that nobody else is watching the screen from a side.

I once had an interesting article for translation which described a study on human perception in various areas of our FOV. Generally speaking, we perceive a lot more things in the lower half of it but it also depends on the colour (or rather contrast of the object against the background), size, if it moves, how it moves and how quickly it happens. There are a lot of dependencies which are a result of evolution (we are a hunter species, after all). The images in the patent show FOV divided almost exactly like I remember from the article. If they get it right, VR might get a lot better than it is now, elevating it from a gimmick to a groundbreaking experience in gaming. VR games won't have to look worse than "normal" games anymore because the actual FOV will be much smaller with the rest being rendered at much lower quality but you won't notice it due to how our eyes work (and how brain interprets their vision, most of all).

Well actually there are also gaze trackers for pcs. So you could use some of this stuff in the patent to reduce rendering cost on pcs too.
You could focus rendering on the players eyes focus and reducing rendering quality on everything else.
As gamers seem to move towards bigger widescreens (and curved screens!) this could be helpful in these cases.
 
Last edited:
I'm not a coder, but it does read like foveated rendering for VR. The numerous mentions of eye focus, as well as the explicit reference to foveated rendering in paragraph 45, gives me the impression that this is a means of allowing improved geometry detail at the focal point in VR games. Some kind of dynamic tesselation taking place outside of that focal point, to cut down on what needs to be computed/rendered to allow maximum detail where it matters. Probably a remedial read of the patent, and probably something all VR engines strive to achieve anyway. But does this mean that there will be eye-tracking in the VR headset? I don't have one, so I don't know how common that is.

My initial read of the abstract was just that it was some fancy LOD blending based on distance from the viewer, but this seems more focused where the viewer/camera is focused. I assume the vertex weighting of the partitions are adjusted based on that. I can read the patent, but as I don't understand how it all works with actually converting 3D to 2D display, much of it escapes me. I find your posts helpful in distilling it, but I'm also not certain how well you're interpreting it. Certainly better than me, though.

Eyetracking is something thats been talked about a lot but not yet widly spread in Consumer VR Products afaik. I think this stuff seems to be emerging just now (including the past year or two ).
 
Top Bottom