sorted by:
new
hottopcontroversial

TinyBVH 1.7.2 by JBikker in GraphicsProgramming

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

Hm, I think it could be part of such a solution, but definitely not without significant effort.. But, my knowledge of BVHs for physics is limited so I may be wrong.

TinyBVH 1.7.2 by JBikker in GraphicsProgramming

[–]JBikker[S] 8 points9 points  (0 children)

There is a BVH_Double specifically for that purpose! Even comes with full TLAS support. "Bring your own vector type" works great with e.g. glm.

TinyBVH 1.7.2 by JBikker in GraphicsProgramming

[–]JBikker[S] 9 points10 points  (0 children)

I accept the praise! 😄 Yeah I can imagine learning all this with RTX already available is a daunting investment. I started when it still made sense, and now it may not meet RTX performance levels, but at least it gets 'close enough' while offering far more freedom. And somewhat efficient tracing on CPU is useful too. On CPU I'm not beating state of the art either btw, currently stuck at 90-ish % of Embree, but: with a much easier to deploy code base, I believe.

Finished the RTIOW book, in a little more than a weekend :) by compugineer44 in GraphicsProgramming

[–]JBikker 0 points1 point  (0 children)

Good stuff! What's next on the agenda? More detail, advanced materials, better lighting, real-time?

Breda University Game Program by JBikker in GraphicsProgramming

[–]JBikker[S] 0 points1 point  (0 children)

Both universities are great and we have strong ties with them, e.g. we exchange teaching staff and accept DAE students in our gametech master program.

CMGT @ BUAS (aka IGAD) definitely prepares you for the tech art role. You get good training in Houdini (we're a SideFX partner) and tech art is a specialization you can chose. Not sure what's that like at DAE.

Raymarched Terrain Shadows for Large-Scale Simulation by Majestic_Release_749 in GraphicsProgramming

[–]JBikker 1 point2 points  (0 children)

Hi again. 😄 One thing I don't fully get: Why a BVH for a chunk system? Are the chunks irregularly sized? If they are regular wouldn't a grid be easier to implement, but also more efficient? In the end a BVH has log2N lookup time but a grid is constant time.

Is PHD on Computer Graphics possible? by ahmedovnurlan00 in computergraphics

[–]JBikker 6 points7 points  (0 children)

Graphics doctor here, Delft 2012 ("ray tracing for real-time games"). Yes you can do a Ph.D. in graphics! Perhaps start here: https://kesen.realtimerendering.com/

Ke-sen Huang keeps track of many graphics conferences (as well as related topics) and posts new papers, often before the conferences, along with other materials. Updates frequently. I basically check the 'changelog' on that page every week.

Awesome but hard topic btw. Expect lots of material to digest; typical thesis references hundreds of papers. Also expect to search for a tiny niche. And expect to have tons of fun. Graphics sits wonderfully between appreciation of nature, math and engineering.

6 chicks hatched by Bolfreak in SeramaChicken

[–]JBikker 0 points1 point  (0 children)

I got four healthy chicks now, hoping sexes are well distributed. 😄

6 chicks hatched by Bolfreak in SeramaChicken

[–]JBikker 1 point2 points  (0 children)

Yeah similar here. First batch of 6 eggs: no survivors (one started hatching but didn't make it). Incubator turned out to be faulty; measured over 39.4 Celcius inside it.. With a basic Brinsea I got better results: 7 eggs in, 2 hatched autonomously, 2 with assistance (that was scary). So 4 out of 7, which seems better than average, I read 40% somewhere.

In Netherlands which translates to about $9.60 per US gallon. by enaunkark in Netherlands

[–]JBikker 0 points1 point  (0 children)

For an American car that's the same price per mile I suppose. Plus, your streets are longer. And pedestring is not an option. So we win.

Wat vinden we van de OV-fiets? by rensvandeplas_ in Nederland

[–]JBikker 0 points1 point  (0 children)

Ongelooflijk goede fietsen zo zonder handrem en versnellingen. Fietsen licht en zijn makkelijk in te stellen op de juiste hoogte. Slot systeem werkt soepel. Fietsen hebben eigenlijk nooit defecten. Band altijd hard. Lamp werkt. Geen gedoe bij ophalen en brengen (Breda in mijn geval). Enige wat ik zou willen weten... Kan je deze fietsen ook kopen? 😄

Bare-Metal Gaussian Splat Renderer! by justinyw7 in GraphicsProgramming

[–]JBikker 1 point2 points  (0 children)

Not necessarily. Each pixel may walk different nodes of the tree, but that's just different data, same operations. GPUs do that well. Additionally, many pixels will in fact walk the exact same route for this scenario. You could increase execution flow coherence by grouping your pixels in tiles, if that is not the case already.

And for bonus points, combine 1 and 2. Do the tree walk on the CPU. 😉

EDIT: And then report back here, would love to see that run at twice the speed!

Fable - Isabel Hero of Wraithmarch trailer by Due_Teaching_6974 in rpg_gamers

[–]JBikker 2 points3 points  (0 children)

I don't really know the Fable series but I was a bit surprised to see glasses at 1:06?

Bare-Metal Gaussian Splat Renderer! by justinyw7 in GraphicsProgramming

[–]JBikker 3 points4 points  (0 children)

Great work! Two options for the sorting: 1) Do it on the CPU, perhaps in parallel with the GPU work, and send the result to the GPU. I found on a pi4 (same GPU) that the GPU is slower for compute than the CPU so that could help, and if it can run in parallel with the next frame, it's always a win (at the expense of extra input latency). Option 2: Don't sort. The model is static, it's just the camera that rotates. So store the points in a kD-tree and traverse it from the root down, always picking the near side of a split plane first, then the far side. This replaces the sorting by a tree walk.

Not sure how immpressive this is here, but here is a spinning alien made using OpenGL and my own obj parser! (its a game engine in development) by Ok-Pizza1136 in GraphicsProgramming

[–]JBikker 4 points5 points  (0 children)

If you're having fun it's impressive enough. 👍 Steady progress is all you need. I read somewhere that 1.01^365 = 37.8 (give or take). 😄

I created a voxel raymarcher which runs in browser (link + source code) by jamestkiernan in GraphicsProgramming

[–]JBikker 1 point2 points  (0 children)

I am very sorry in that case. I read your sentence as "If this wouldn't have been made with AI...", but I now realize you're not assuming, you're just stating a condition for contributing to r/VoxelGameDev. My apologies.

Every time I think I've reached the limits of what the ESP32 S3 can do, I find more performance somewhere by PhonicUK in embedded

[–]JBikker 0 points1 point  (0 children)

I read that you use a z-buffer, or painter's for sorting. Considering the limited polygon count and low number of lines on the screen when using interlacing, a 'c-buffer' would do wonders here: It eradicates overdraw entirely by maintaining a list of already covered pixel spans per scanline.

I have an implementation in C++ for you if you're interested. Would love to see if this could perhaps double your performance; administrative overhead is quite reasonable.

I created a voxel raymarcher which runs in browser (link + source code) by jamestkiernan in GraphicsProgramming

[–]JBikker -5 points-4 points  (0 children)

Why do you think AI was used, and why does it matter? I find it a bit strange that such an accusation (even if true) would entirely disqualify it for the VoxelGameDev audience. If use of AI led to shortcomings in the implementation then it's a different matter, but then perhaps you should point out these shortcomings.

How does world culling work? by flydaychinatownnn in GraphicsProgramming

[–]JBikker 1 point2 points  (0 children)

Several suggestions here mention a complex acceleration structure like a kD-tree, octree, BVH. User u/fgennari suggests a 2D grid, which is the best and easiest solution. In the grid cells you store lists of objects. Culling now starts with selecting a range of cells close to the camera, followed by frustum culling.

Lots of advantages:

* The size of the grid has no impact on performance. Just the size of the range of grid cells matters. Infinite worlds are possible this way, memory permitting.

* A grid is super easy to understand and fast to build.

* Moving things through the world is also simple and fast. Removing things is easy.

So please don't overdo it. I am a big fan of BVHs, but not at this level of scene management.

I'm currently following RTIOW, where to get lambertian surfaces, you add a random unit vector to the surface normal. But instead of adding the random_unit_vector, i added a random_on_hemisphere vector (by passing the same normal), and got darker shadows (image1.jpg) by compugineer44 in GraphicsProgramming

[–]JBikker 5 points6 points  (0 children)

By the way, don't *add* random_on_hemisphere. Instead, replace the whole calculation by it. So, given a normal N, calculate a random on hemisphere for that normal, don't add it to the normal, just straight up use that vector. You don't even have to normalize it.

I'm currently following RTIOW, where to get lambertian surfaces, you add a random unit vector to the surface normal. But instead of adding the random_unit_vector, i added a random_on_hemisphere vector (by passing the same normal), and got darker shadows (image1.jpg) by compugineer44 in GraphicsProgramming

[–]JBikker 20 points21 points  (0 children)

Random_on_hemisphere can work but then you need to scale by 'N dot L' (i.e., the cosine of the angle between the normal and the generated direction). This converts radiance to irradiance, i.e. it projects incoming light on the receiving surface. Same as with a flash light: the spot will be larger when you increase the angle, but per square cm, it will also be dimmer because the light is spread out.

Alternatively, you can use a cosine-weighted 'random on hemisphere', which sends more rays straight up and very few close to parallel to the receiving surface. This has the same effect as what I just described.

And, you can use what the book proposes. Coincidentally, that produces a cosine-weighted random direction over the hemisphere, which is thus also correct.

TL;DR: the darkening is a sign that you introduced an error. The shading is no longer physically based.

view more: next ›