mosra/magnum

Lightweight and modular C++11/C++14 graphics middleware for games and dataviz

Vladimír Vondruš

@mosra

i'm on linux anyway, so i'll just grab the code and see :)

even just the cpp file is enough

irfna

@irfna

Ok, this is just the cpp file, I have imagepath at the top to be filled out with an image path, and can grab my really poorly drawn images as well

https://drive.google.com/file/d/1yMYjLDUgi4kOj0WBvigfm0pOQVMvOoil/view?usp=sharing

Here's the images

I changed it to using flatGL instead of phong in the mean time, so it will be using the flat shader in the pastebin, the error is clearer with it though I think

Vladimír Vondruš

@mosra

hmmm i get the same issue

investigating...

irfna

@irfna

I really appreciate the help!

Vladimír Vondruš

@mosra

btw, i find this hilariuous:

GetImage("dirt.png")

GetImage(object.png)

had to take a double look until i understood how it can even compile :D

irfna

@irfna

hahaha oops ya I should have fixed that debug output, I was copying and pasting example code

This is more of a test run of various features I need than making the actual game proper

Vladimír Vondruš

@mosra

okay the problem seems to be here:

.setProjectionMatrix(Matrix4::perspectiveProjection(35.0_degf, 4.0f/3.0f, 0.001f, 1000000.0f))

the near/far range is so huge that it's beyond what can be represented in a (I assume) 24bit depth buffer, and so the cube front and back faces get assigned the same depth value, which makes the output depend on the order the GPU processes the triangles and not the actual depth

i went with 0.1f, 10000.0f and it started looking acceptable, but if you see similar artifacts later you might want to narrow it down even further

irfna

@irfna

Ah I see, so I'll have to make sure everything gets scaled down a bunch so I can reduce that value

Vladimír Vondruš

@mosra

more like finding the right range

irfna

@irfna

Thanks, I knew it had to be some small thing like that

Vladimír Vondruš

@mosra

for example if you have everything 10 or 100 units from the camera anyway, then it doesn't make sense to make the near value so low

irfna

@irfna

Ok, I see

Yep, switching to 10.0f to 10000.0f seems to fix the issue completely!

Thanks for the help! Now all I have to do is figure out why the sprite transparency isn't working even when I enable blending haha

Vladimír Vondruš

@mosra

you need to call setBlendFunction() as well :)

irfna

@irfna

Cool, thanks!

Vladimír Vondruš

@mosra

actually i can't seem to get it work myself :D only AlphaMask enabled on the shader did work

what am i doing wrong?

ah, no, actually

Vladimír Vondruš

@mosra

this is it:

    GL::Renderer::enable(GL::Renderer::Feature::DepthTest);

    terrain.draw(*_camera);

    /* Draw sprites after the terrain, so it's obscured by it if it's behind.
       But disable depth writes, so the sprites don't cut into each other */
    GL::Renderer::setDepthMask(false);
    sprites.draw(*_camera);
    GL::Renderer::setDepthMask(true);

    GL::Renderer::disable(GL::Renderer::Feature::DepthTest);

before you had sprites rendered first, and they wrote to the depth buffer so the cube wasn't rendered behind it

the AlphaMask (and no blending, or depth ordering) works as well, but that's a purely binary operation (a pixel either is there or is not), so it looks acceptable only on sufficiently high-DPI screens and won't work for semi-transparent stuff

irfna

@irfna

haha I hadn't actually tested when you said to use setBlendFunction and had to go afk at the time, sorry for making you think I got it to work with that. For sprites, alphamask is all I need for now, although someday I will need to be able to make things semi-transparent

I'll copy and paste that change into my code

Vladimír Vondruš

@mosra

it always ends up being more complicated than it seems at first

irfna

@irfna

Ya, I see what you mean. Luckily the extra complication has been fairly small one line things, it's just knowing that they're necessary that is the issue haha. I tossed setBlendFunction in along with the code snippet you pasted, and the sprite transparency is working great

Thanks a bunch, you cut through some stubborn issues for me just like that

Vladimír Vondruš

@mosra

last thing, while i have the code here -- it ~~crashes~~ asserts on exit due to the global manager that holds OpenGL objects, the ideal fix would be to make it a member of the Application class, so it gets cleaned up before the Application itself destroys the OpenGL context

irfna

@irfna

Alright, thanks! That's an easy enough fix

Mathew

@lectroMathew

PhongMaterialUniform::shininess doesn't make much sense to me: the larger value, the harder surface. Shouldn't it be called hardness then? :D I wonder why GL_SHININESS works in this way...

Vladimír Vondruš

@mosra

this is where it originates: https://en.m.wikipedia.org/wiki/Phong_reflection_model

Mathew

@lectroMathew

Yeah, again

constant, which is larger for surfaces that are smoother and more mirror-like.

I guess you can say that mirrors are not shine because they don't have any specular highlight? In my head tho it's always been like the reflection itself is just a big specular hightlight. A bit counterintuitive...

pezcode

@pezcode

I guess you can say that mirrors are not shine because they don't have any specular highlight

That quote says the opposite, doesn't it? Mirror-like = large shininess

mirrors are 100% specular reflection, virtually no subsurface scattering

Mathew

@lectroMathew

I guess you can say that mirrors are not shine because they don't have any specular highlight

That quote says the opposite, doesn't it? Mirror-like = large shininess

Is what I think as well, but read further:

When this constant is large the specular highlight is small

shininess value of 0.0f results in perfect mirror-like look

pezcode

@pezcode

highlight size is (very loosely speaking) inversely proportional to the amount specular reflection

shiny surface -> small highlight

Mathew

@lectroMathew

Yeah, I guess it does make sense if you think about it

Vladimír Vondruš

@mosra

could anybody on Windows run the following and tell me if it all passes or mostly fails? it all passes for me on Linux with both Chrome and FF, but on the Windows machine I tested on it was about 40 failures and I don't know why :D

https://tmp.magnum.graphics/GLMeshGLTest.html

9 replies

i only wanted to fix that one ANGLE bug, but apparently there's a bottomless pit full of bugs, again

Azvf

@Azvf

Hi, I'm trying to blit a framebuffer to the right half of the defaultframebuffer, but why the right half keeps thrashing when I scale the window in width. It seems the resize function problem but it works fine when I use the 'default' blit.

Azvf

@Azvf

It keeps switching between the black screen of the defaultframebuffer and the data in the source framebuffer

Where communities thrive

People

Repo info

Activity