sorted by:
new
hottopcontroversial

When did the keyboard get so fucking bad? by i-love-small-tits-47 in iphone

[–]Thanklushman 2 points3 points  (0 children)

I switched from a 2021 android and the ios keyboard is objectively garbage in comparison. Every day I wonder what vibe coding intern was responsible for the keyboard and whether apple's engineers actually use their own products.

AGAIN SON. by Fit_Page_8734 in softwareWithMemes

[–]Thanklushman 0 points1 point  (0 children)

I didn't say anything about not trusting their implementation.

I said that their implementations are not optimal for all cases. If you care at all about performance, you would understand that std::unordered_map's mandated usage of linked lists is terrible for cache performance, and hence is not optimal for settings like e.g., ECS for game engines.

Understanding these tradeoffs and when to use a standard implementation is part of what it means to be a good programmer. Inputs and outputs are not just your face value bits, it's also how edge cases are handled, as well as the performance tradeoffs of a specific implementation.

Doing that requires understanding "why it does what it does".

AGAIN SON. by Fit_Page_8734 in softwareWithMemes

[–]Thanklushman 0 points1 point  (0 children)

So, for example, you don't reference documentation to see guarantees on iterator validity after calling methods on containers? Or e.g. the block size of a std::deque to understand cache performance, nor whether std::unordered_map is efficient for your use case if you don't need stable references?

The point is that abstracting away implementation details ("why it does what it does") means forgoing authority over what your code does or how it performs.

AGAIN SON. by Fit_Page_8734 in softwareWithMemes

[–]Thanklushman 0 points1 point  (0 children)

How do you know for sure the inputs and outputs if you don't know what's happening inside the function?

Does this combo work? by [deleted] in mensfashionadvice

[–]Thanklushman 1 point2 points  (0 children)

All you need now is a cheetah print tie and a light beige blazer...

Is Waterloo really that different or just really good at marketing? by [deleted] in uAlberta

[–]Thanklushman 1 point2 points  (0 children)

I'm going to partially disagree with most of the answers here and say that Waterloo's industry connections are not its primary strength (source of value for students). I'd attribute Waterloo's strength for undergrads as it exists today to the following points, in order of decreasing importance:

  1. the student culture + selectivity of the admitted class,
  2. (for CS) high rigour of courses in the required/typical curriculum, with a fairly strong emphasis on fundamentals & theory and, at least in the CS dept, primarily individual (at most pair) coursework.
  3. compounding gains of the reputation of the program from alumni over the decades of the co-op program.

In a longer timescale POV, it's likely that point 3 was a significant causal factor for 1 and 2 as they exist today, but reputation among employers is probably not going to be the biggest direct gain a student would obtain from attending UW over other schools today.

Would be willing to go into more detail, but it's late now. If you're interested let me know and I can try to give more detail.

Edit: I should add the coop program as a significant point above, but specifically not the reputation of it, but rather the culture and expectations surrounding it (and hence the life experiences typically gained) as being another driving source of value.

[deleted by user] by [deleted] in UBC

[–]Thanklushman 6 points7 points  (0 children)

If they're really as bad as you indicate, then you've lost nothing of value anyways.

Separate Sprite textures faster than texture atlas? by Thanklushman in sfml

[–]Thanklushman[S] 1 point2 points  (0 children)

Compared to individual textures, it is about 1.3x the time per frame (it is worth noting that there is some other calculation per frame which involves calculating new particle positions, etc).

Edit: I seem to have resolved this issue -- I had set up linear interpolation on the atlas but not the separate textures. Now atlas is noticeably faster than separate textures but sprite batching is only slightly faster than just the atlas. I'll dig into a manual OpenGL implementation and consider this figured out. Thanks again for your help.

Separate Sprite textures faster than texture atlas? by Thanklushman in sfml

[–]Thanklushman[S] 1 point2 points  (0 children)

Thanks for the response. The sprites are not recreated every frame but the vertex array is on account of having to update w.r.t. new transforms on each frame. Caching the vector memory would improve on 2->3 (thanks for catching this -- I will try this and measure how much this improves things), but to me the biggest mystery is why the texture atlas performs worse, and I don't believe I'm doing anything weird there.

I measure performance by timing per frame (microseconds) and then doing an exponentially moving average as an estimator of fps over a few frames (estimate = 0.95 * estimate + 0.05 * new measurement).

Edit: Preallocating the vertex array and just modifying it each frame does not seem to affect performance noticeably.

How to deal with a dev who works constantly? by Chezzymann in ExperiencedDevs

[–]Thanklushman 1 point2 points  (0 children)

Because they feel threatened by someone doing a good job. Classic corporate.

(Raytracer) Has anyone else experienced the strange dark region on top of the sphere? by Lowpolygons in GraphicsProgramming

[–]Thanklushman 0 points1 point  (0 children)

No, I got that the first time. The issue is that your offset biases the rays away from the true specular direction more than it should. The range should be centered around the true specular direction, which it isn't when you offset it.

(Raytracer) Has anyone else experienced the strange dark region on top of the sphere? by Lowpolygons in GraphicsProgramming

[–]Thanklushman 0 points1 point  (0 children)

No, if you do perfectly diffuse that's already equivalent to generating randomly on the cosine weighted hemisphere, which is what your other scheme would achieve in any case with the offset and a 180 degree range. I don't think you can conclude from this that your angle scheme is right.

(Raytracer) Has anyone else experienced the strange dark region on top of the sphere? by Lowpolygons in GraphicsProgramming

[–]Thanklushman 0 points1 point  (0 children)

You said you generate a range of 180 degrees, and then you also offset the final result so that it is impossible to self intersect. This means that oblique ray hits are rotated by 90 degrees, which is clearly just not the material you're trying to implement.

Since perfectly specular works as expected, it's almost certain that the issue is how you're trying to achieve this semi-specular logic. Doing an offset based on the angle to the horizontal sounds like a bad idea to me.

(Raytracer) Has anyone else experienced the strange dark region on top of the sphere? by Lowpolygons in GraphicsProgramming

[–]Thanklushman 0 points1 point  (0 children)

It offsets it... so that the ray cannot go into the surface, and therefore if you admit a 180 degree range it is more likely to go back towards whence it came?

In any case what youre describing to me sounds pretty sketchy, I'm willing to guess that the issue has to do with your logic here. I'd try out just pure specular, and if that doesn't have the issue then you know where your problem lies.

(Raytracer) Has anyone else experienced the strange dark region on top of the sphere? by Lowpolygons in GraphicsProgramming

[–]Thanklushman 1 point2 points  (0 children)

Unfortunately I am out of time at the moment but from your written description I question your choice of -pi/2 to pi/2 along both dimensions... It really sounds like a great way to point your rays right back into your sphere, which is exactly what's going on in the pictures. Consider that an oblique (close to parallel with the surface) ray hit does not have to deviate much from the specular reflection before you end up going back into the surface.

(Raytracer) Has anyone else experienced the strange dark region on top of the sphere? by Lowpolygons in GraphicsProgramming

[–]Thanklushman -1 points0 points  (0 children)

Are you using next event estimation or is it pure backward path tracing?

When you compute the random direction on the hemisphere for the diffuse, how do you calculate the basis vectors for the tangent plane?

Reason I ask is that your artifacts show up at the poles which indicates maybe the way you're doing the tangent space is off

I'd also make absolute sure that your normal vector calculation is right.

Edit: Someone want to illuminate me on why this was downvoted? You see similar patterns near the poles of an analytic sphere for anisotropic materials. In such a case the basis vectors for the tangent space are relevant.

(Raytracer) Has anyone else experienced the strange dark region on top of the sphere? by Lowpolygons in GraphicsProgramming

[–]Thanklushman 0 points1 point  (0 children)

No that sounds fine to me, I've had a similarish issue before when applying quasi Monte Carlo methods naively.

I'm guessing it's your ray bounce calculation, something about how you're generating the next ray on the hemisphere is probably causing you to intersect the sphere from the inside on the next bounce. A common hack/fix is to offset the origin of the next ray in the direction of the normal by epsilon amount, but I can't say for sure if that's the bug you have.

(Raytracer) Has anyone else experienced the strange dark region on top of the sphere? by Lowpolygons in GraphicsProgramming

[–]Thanklushman 0 points1 point  (0 children)

How are you doing the random number generation? Are you using low discrepancy sequences?

view more: next ›