Still no true opengl surface displace support for cycles openGL?

well…in eevee it may work, but…I want surface displace to show up in the openGL without having cycles activated, and without using evee, is this still a limitation in blender 4.2…I heard a rumour that could have been adressed…if not just pertaining eevee.

But after testing in blender 4.2 alpha …I do not see that working.

So you want shader based displacement working without showing shaders?

The solid view is the workbench engine and intentionally has as few bells and whistles as possible. The textured view is just Eevee.

If you want to see surface displacement in solid view you have to actually displace the verts, using a displacement modifier or geometry nodes.

Eevee next, (Eevee in 4.2) does do shader displacement. That is probably what you heard about. But solid view is not Eevee.

1 Like

correction.
I think I mentioned, eevee isn´t an option, or should not pertain eevee, I know it can do that.

I also know you can use the modifier, but that is not the same as the surface material displace.

And Rayek showed it can be activated with the material shading for the opengl, so eevee isn´t needed.

I tried in blender 4.2 alpha, not working though, but he used later 4,.2 version …which worked it seems, so I just have to download the latest version.

no…no …no.
I want surface displacement through nodal material setup to show the displacements in open GL, and exclude everything about eevee, I want to use cycles as rendering engine and wouldn´t like to swap between those two just for the sake of seeing displacement in the openGL viewport, nor would I like to be limited to using cycles interactive renderer only for setting things up and moving around, that should happen in open GL.

Anyway…I think case is solved, Rayek informed me about this on a Lightwave discord channel, where he lurks sometimes, and he checked this up to be working with the material shade mode, as for solid mode, not sure if it works.

Need to install the latest blender version, I tested in 4.2 alpha…and it was probably not adressed in there.

The textured view just eevee? In cycles mode, I don´t think so
Then it would make no sense to have that mode in the first place, or why even switch render engine, when you can click on the textured view in such case?

Eevee uses the open GL as the core as I understand it, but more enhanced when active…

Memory Usage

Eevee uses OpenGL, and GPU memory management is done by the OpenGL driver. In theory, only the needed textures and meshes needed for one object need to fit in GPU memory at a time. This is because OpenGL only needs the resources for one draw call at a time.

If you mean Material Preview, yes, it’s always Eevee.

3 Likes

Like Joseph mentioned, the “material preview” mode is Eevee. You don’t need to enable or disable anything, or switch to Eevee to use it. That is automatically done. The regular viewport modes don’t support those kind of shaders because of performance considerations and other reasons.

To be clear, we are talking about the “material preview” mode, not the 'texture" display viewport.

image

this sounds wonky and not right to me, but…we can disect this:)

So you are enabling the eevee render engine then? that can´t be true.
The viewport in material preview and render when activated in eevee…is different, not the same.
it doesn´t account for what you enable with the evee engine for the whole scene, so I just question calling it eevee, when it seem to be more just being the openGL, enhanced.

as I refered to, in the docs, eevee uses openGL, what incites to call it …eevee?
Is the material preview really refered to as eevee when you work with cycles …in the docs?

yep…the material preview as you referenced with the screenshot on the modes.

Edit…
Well…yeah, I forgot to enable the scene lights, scene world.
Now it definitely matches the render viewport mode, need to check more.

It’s affected by render properties under Eevee section. The material view specific code is under Eevee internally, as it is Eevee. Why wouldn’t you call it Eevee?

It is, though.

2 Likes

See my post after the post you qouted :slight_smile:
Might be a little change of perspective to a validation of that. :slight_smile:

so one thought more…
Wouldn´t solid mode be a more True openGL, as not really employing some viewport “rendering”
that increases time of the viewport refreshment, sure it will lack materials, but for the case when you only need to see the displacement in the viewport as smooth as possible.

The question is if there is some difference there in speed, and if it´s also possible with the latest blender version to also use the solid shading mode for displacement when using surface displace, I guess not?

The displacement modifier works, that we know…so let´s not bring that in to the discussion.

They are all the same, work on the GPU drivers. You might need to modify your conception of what OpenGL is. Whatever you think of OpenGL is blindsiding you.

“Eevee uses OpenGL, and GPU memory management is done by the OpenGL driver.”

5 Likes

As far as I know “solid” (Workbench Engine) and “material preview” (Eevee Engine) are both eevee with various things turned on and off. Something I’ve been asking for is a dedicated shader output node for Workbench like we have for Eevee and Cycles. If we had that we could plug in the displacement node to see the effect in workbench even though we wouldn’t see any other aspect of the material and it might not be compatible with the basic flat texture display available in workbench, but in our situation we probably don’t care about that. We only want to place our houses quickly and accurately on the displaced ground and only need to see the displacement in solid view to achieve that.

I wouldn’t go that far, as Workbench is listed as a separate engine and has it’s own specific effects and render pipeline. It’s more of it’s own thing, compared to material preview that is just few conditionals in Eevee code for minor differences under material preview mode by default.

Yes I may.

1 Like

I’m curious to hear your description of what openGL is in the context you speak of

I honestly do not know enough of openGL tech to describe it well.
What I wanted to exclude when I defined it as in terms of True openGL, was the refreshing rates as if it has to calculate rays in such a way it really is rendering and adding additional time to do so in the viewport display.