@DMGregory hahahah

Series X what the FUCK hahaha

Hello! How to tell if the game is framerate dependent?

without looking the code

@Tyyppi_77 That is indeed annoying. I strongly dislike the design decision to require everything you assign to std::function to be copyable. The best solution I can think of is making your own function type that supports move-only callables and is not copyable, but that's a bit of effort and unless you spend significant time on it you won't have the small function optimization.

Maybe some of this is reasonable.

On the other hand reimplementing std::function is what counts as fun for me and I think it's starting to count for you too :P

std::future's destructor blocks iff the std::future was created by std::async and the task is still running.

And wasn't moved from.

I think it does. I don't know why they said "may".

The exact rules are a bit tricky, but I'm fairly sure it does the intuitive thing. You can manually create an std::future and move an std::async std::future into it and it will still block, so technically "created by std::async" is incorrect.

Morning

Good morning.

Weather will give us a break from the heat wave..

Yeah, we got some nice storms here last week that cooled things off.

Yeah, this came here during the weekend!

One evening, there was a lightning storm, but no rain!

Very excited that we got to officially announce our game over the weekend. 😁

FarCry are good shooter games.

Haven't played Far Cry 5 yet, though.

Thanks! I hope you'll like this one. 😊

I'm late on my games-to-play list :)

I'm buried under mine.

Well, if I need to shoot "bad guys" (in the head, preferably), and there is a good story to keep me hooked, I'll most likely like it :D

I vaguely remember playing FarCry 1 or 2 and spending like an hour in the first part to be stealthy and failing over and over. For some reason I made it a goal to play "properly". But eventually I gave up, shot the first guy with a machine gun and then just killed everything on the map. It was effective but not the game I wanted to play.

Maybe I should give the new ones a try some day. They probably improved on that.

I think the "DeusEx" games allow you to be more stealthy in general.

@nwp We're certainly trying. :) A fair portion of the team, including our AI designer, are Splinter Cell Blacklist vets, so it's a playstyle dear to our hearts.

I loved this trailer from our friends downstairs on Watch_Dogs too:

Hey, stop it, I haven't played Watch Dogs two yet, You guys are adding too much stuff on my list!! :P

I'll confess I haven't either. The "Play as Anyone" mechanic has me fascinated to jump right into this one though, even without a full catch-up on the series.

plays as a tiefling warlock who was abducted by mages who tried to use him to safely extract knowledge from a captured demon

I did not watch the trailer :) In any case, I wait until the game is out before I buy.

@nwp Sounds DragonAge to me ;)

I mean, if you can find that guy in London, absolutely, recruit him!

It was a DnD concept I had at some point but never got to play.

Sounds like it'd make for a cool campaign.

This story about Sony investing in Epic Games got me thinking... Since a chinese company that also works on a "social credit" infrastructure in that country owns 40% of epic, are we taking part in oppressing people's liberties there if we give money to Epic?

Very indirectly. Technically doing business with China strengthens China. But not doing business with China is difficult and expensive. Also it's not clear if the wealth increase will be a benefit or a detriment to oppression.

So we're all doomed?

:P

But the wealth increase for that company could fuel other parts of its business and that would contribute to oppression. But at the same time, if a company does not make money with a field of activity, it shuts it down, so one could assume that oppression in itself is a lucrative business.

I like to think over time and with better technology these problems will get solved. I also like to think that oppressing people gets you cheap dumb labor which is becoming increasingly obsolete since machines can give you better even cheaper labor, so such oppression will just be dropped since it's not actually lucrative.

But realistically we're probably all doomed.

Also I wasn't aware that Epic Games was in the oppression business.

@nwp Yeah I wonder how much you can oppress people. Do they rebel at one point?

@nwp Who knows!

We appear to be on course to find out, for better or for worse. :(

Quick question, writing my computer graphics exam tommorow... Flat shading in OpenGL is basically all vertices of a polygon using the same normal... How exactly do we proceed with gouraud shading ? Do we use every vertex as its own normal ?

Don't you need to pass the normal with your vertex?

doesn't sound like it

"Gouraud shading is most often used to achieve continuous lighting on Triangle meshes by computing the lighting at the corners of each triangle and linearly interpolating the resulting colours for each pixel covered by the triangle. Gouraud first published the technique in 1971."

Thanks ! But how do the normals behave ? Flat = All vertices share the same normal, Gouraud = All vertices calculate their own normal ?

So if you set the same normal to each of your vertices on the same surface, and you implement Gouraud, you end up with Phong anyway?

Hmm, ok, haven't been into those spheres much lately. In fact, I nearly mentally skipped those at school :P

Alright, thanks... so each vertex has its own normal which gets calculated by crossing ( cross product ) the local vertex with its next neighbours i guess, right ?

You might want to unpack that a bit. "multiplying vectors" can be done multiple ways, and I suspect the one you have in mind might not be appropriate here.

Thanks, just changed it to "crossing" -> cross product... because thats how you calculate the normal was far as i know ^^

I have an answer here that shows a common algorithm we use for this:

Thanks ! Im gonna take a look at this :) Is there a difference between face normal and vertex normal ?

Vertex normal can be used in shading; face normal can be used to decide if you see it or if you don't.

And both of those getting calculated in different ways ?

Often we'll automatically calculate the vertex normal from the face normals of the faces surrounding it.

I think so; as Tyyppi_77 said, the vertex normal will be generally calculated by the modelling software; while the face normal could be determined partially by the winding order of the vertices.

(and the position of those vertices)

Damn... our prof never mentioned this... I assume youll need face normals for flat shading, vertex normals for gouruad and phong, right ? In this case my flat shading was totally wrong

Combining all that has been said, the vertex normal needs to be determined in accordance with the shader that'll be using them.

The face/triangle is the only thing that has a well-defined normal, geometrically. A vertex, being a point, doesn't really have an orientation or direction. We choose to associate a normal with a vertex to express "how the surface 'near' this point is facing" - but there's some room in that to choose different definitions or even outright make stuff up. ;)

So sometimes an artist will paint the vertex normals to face a different way than what the faces around them would suggest, in order to achieve a particular look. We did it on my first game to avoid lighting seams where two tiles met.

It's all super fuzzy and math-y and it's why shaders and rendering never really interested me :P

@DMGregory What a pain.

The way I'd look at it is that it's just data. There might be a simple/obvious/usual thing to do with that data, but it's also in your control to put in whatever the heck kind of values you find useful for your current aims.

All we learned is that "A x B = Normal Vector"... like this prnt.sc/th2ydm piece of code, i bet this is called the "vertex normal" right ? And the code you posted @DMGregory is used to calculate the face normal ? ^^

It depends what A and B are. ;)

If A & B are two edges of a triangle, then indeed the vector A x B will point perpendicular ("normal") to the plane of that triangle.

And the face normal on the otherside simply repeats this step for each combination of vertices inside the polygon ? math.stackexchange.com/questions/305642/…

Usually our polygons are triangles, so we only need to compute the normal once per face, no repeats.

If you have non-triangular faces, then you have the possibility that the face does not lie all in one plane (picture a square folded along its diagonal), and it becomes a matter of convention how you label "the" normal of such a surface.

Alright thanks :) So in this case i calculated the faces the right way... now i only need to understand vertex normal calculation

For that, we'll usually average the face normals of all the faces surrounding the vertex, weighted by their area.

Or, as mentioned above, just use whatever normal was given to us for that vertex from the model file. The mesh might have been saved with completely arbitrary normals if that's what the artist intended. ;)

"please use these random vertex normals, and apply a random quaternion to it before applying the shader. Thanks."

Masks will be mandatory in all indoors public spaces in our province...

We put that in effect recently in Toronto. It's done wonders for compliance at the grocery store!

The week before I saw one mask, around someone's chin. This week, everyone was wearing them, and wearing them properly too!

Nice!

It's mandatory starting today in public transit.

Haha that's a must!

"Can we have hats?" No, you get masks. Hats are so last decade.

And im back... i still dont understand one certain aspect... the fragment shader... The vertex shader runs over all vertices in order to prepare data for the fragment shader. But i cant find any information about how often the vertex shader/fragment shader gets called... I assume that its not a 1:1 ratio right ? Furthermore its unclear why we calculate pixel lightning inside the fragment shader...

i only saw examples where the vertex position gets used instead of the fragment position which confuses me because i thought if we wanna calculate pixel based lightning we need to take the fragment position instead of the vertex position.

The vertex shader gets called once per vertex in your mesh. The pixel shader gets called (to a first approximation) once per pixel each triangle covers on your screen/render target.

We call it a fragment shader because sometimes what we're running it on isn't exactly a "pixel". For antialiasing or variable rate shading we might compute more or fewer than one evaluation per output pixel, but you don't really need to worry about that detail for where you're at right now.

Thanks :) what about the pixel based lightning ? If we do the light calculation inside the vertex shader we have flat/gouraud... if we pass the calculated normals/position to the fragment shader and calculate it there we have the same result, right ? Because we simply passed the data... so in order to calculate pixel based light we would need to use the fragment position instead of the vertex position, or am i wrong ?

You are very wrong. :)

@Tyyppi_77 What exactly do you mean ? ^^

This is what i found online multiple times : prnt.sc/th5jvn

Search "per vertex vs per pixel lighting" and you'll get lots of examples like this that show the difference between interpolating the output of the shading function between vertices, compared to interpolating the inputs to the shading function and evaluating it per pixel.

You're making the incorrect assumption that nothing happens to that variable between when the vertex shader writes it, and when the fragment shader reads it.

This is getting interessting... so glsl modifies the variables ? That would explain why lighning inside the fragment shader using the passed position works as expected :o

In reality, the interpolator runs in between these two steps, taking the values from the 3 vertices that make up the triangle, and blending an intermediate value for each variable to pass as input to each invocation of the fragment shader, based on where each fragment is located relative to the vertices.

That makes sense... so theres a hidden unit running between the shaders, searching for the passed positions in order to interpolate them... this wasnt mentioned in the tutorials :/ thanks a lot

It's not exactly a search.

@Tyyppi_77 Thanks ! Im pretty impatient, i actually read the tutorial but stoped before the part with the "more attributes" :/... a bad trait

"I didn't notice this" would be a better way to say that than "this wasn't mentioned" then. ;)

Yeah thats true :/ im gonna work on this behaviour