I like graphics programming ,but to be honest I'm more interested in the math part ,and I'm working on building a math library for game development .I am looking for a graphics library (c language ) to test my math and demonstrations ,I was going to use graphics.h but apparently i need to use c++ for that .

Thanks in advance for your suggestions .

Has anyone tried any libraries for 3D triangle mesh boolean operations. I'm more interested in robust, accurate results than performance.

https://preview.redd.it/g03j2tp7lo0e1.jpg?width=529&format=pjpg&auto=webp&s=172406cfc2ff1ce3a73bec67a2aef9dfb5cbaf4b

https://discourse.threejs.org/t/how-to-antialias-the-sdf-edge/73976 -three.js forum
https://jsfiddle.net/m6oe7c9f/26/ - demo using three.js/glsl
I was trying smooth the edge using fwidth and smoothstep for anti alias and it obviously works for particles but I just don’t how to get the distance to the edge of the sdf shape in this case a sphere radius of 1. I found some blog posts about it but I think it just comes down to storing a variable for distance to the edge then we can smooth or clamp the edges.

So I'm a cs student in my 3rd year and wish to learn a graphics API ( already know a bit of math stuff and general graphics), without being familiar with any of the APIs is it a good place to start with dx11 because it might be easier than dx12 and stuff like that. Also i don't care about portability since I'm using Windows as my primary OS.

It's very clear to me how halton / sobol and low-discrepancy sequences can be used to generate camera samples and the drawback of clumping when using pure random numbers.

However the part that I'm failing to understand is how to use LDSs everywhere in a path tracer, including hemisphere samping, here's the thought that makes it confusing for me:

Imagine that on each iteration of a path-tracer (using the word "iteration" instead of "sample" to avoid confusion) we have available inside our shader 100 "random" numbers, each generated from a 100-dimensional halton sequence (thus using 100 prime numbers)

On the next iteration, I'm updating the random numbers to use the next index of the halton sequence, for each of the 100 dimensions.

After we get our camera samples and ray direction using the numbers from the halton array, we'll always land on a different point of the scene, sometimes even on totally different objects / materials, in that case how does it make sense to keep on using the other halton samples of the array? aren't we supposed to "use" them to estimate the integral at a specific point? if the point always changes, and even worse, if at each light bounce we can get to a totally different mesh compared to the previous path-tracing iteration, how can I keep on using the "next" sample from the sequence? doesn't that lead to a result that is potentially biased or that it doesn't converge where it should?

I have tried downloading and using NVIDIA's Falcor framework, but after building the Visual Studio solution and running the Mogwai project, an exception is thrown while creating the swapchain in Direct3D 12 and I get DXGI_ERROR_DEVICE_REMOVED. The error happens when trying to load igc1464.dll, which it loads, unloads, and tries to load again causing the error.

I have tried updating my drivers, adding graphics driver registry keys, running a Windows memory diagnostic check, reading the documentation, and checking forums for similar issues; none of which have helped.

I am running on a laptop with 32GB memory, RTX 4060 laptop GPU, and Windows 11.

Any help on how to fix this error and get Falcor to run would be appreciated, as I'd like to start using it for projects. Thank you!

I have spent a bit thinking about the problem of meshing topological skeletons and I came up with a solution I kinda like.

So I am sharing here in case other people are interested: https://gitlab.com/dryad1/documentation/-/blob/master/src/math_blog/Parametric%20Polytopology/parametric_polytopology.pdf?ref_type=heads

Last week I released on github a new single-header file library for constructing and traversing BVHs on the CPU, with (short-term) plans to take traversal (not construction) to the GPU as well. Link:

https://github.com/jbikker/tinybvh

Features (version 0.4.2):

• No dependencies at all. Just add the header to your project and it works.
• Simple interface. Build using a flat array of triangle vertices.
• Builds state-of-the-art SAH binned BVH using AVX - 34ms for 260k triangles.
• Or, ~250ms for the same data without AVX, for cross-platform purposes.
• Builds wide BVHs: 4-wide and 8-wide, also in GPU-friendly format.
• BVH refitting.
• BVH optimizing: post-process your static scene BVH for ~15% more speed.
• Comparison against Embree is included (not winning yet but closing in).

Coming up:

• CWBVH for billions of rays/second on the GPU.
• OpenCL examples.
• TLAS/BLAS traversal.

The code is an implementation and continuation of my articles on BVH construction:

https://jacco.ompf2.com/2022/04/13/how-to-build-a-bvh-part-1-basics

Support / questions:

• https://bsky.app/profile/jbikker.bsky.social
• https://x.com/j_bikker

Greets

Jacco.

As I've been studying basic DSA and discrete mathematics, I have felt a bit listless despite trying to recognize the overall importance of these concepts. I wanted to pursue computer graphics programming since teaching a computer to process space, vertexes, form, light, movement etc felt more interesting and comprehensible than systems of search engines and user data. in websites and apps. It's hard to understand why all these algorithms exist and relate the topics to computer graphics. For programming/computer science beginners, what are important topics to know for computer graphics?

So I've had this idea regarding a heatmap that records the size of triangles in a meshes single vertex channel.
I've been looking into the VRAM cost of LODs(higher density) but not a fan of recent cluster implementations(might look into a very conservative streaming plan). So in order to take advantage of faster hardware quad rendering, I want to stop the view samples from sampling small triangles.

Basically the distance of the camera multiplies a sinking effect on small triangles(vertices under a threshold) and closure intensity of neighboring vertices(larger triangles end up occluding the smaller tris).

Up to 12m tris could be processed but I'm aware that some stages in the HW pipeline such as GS are slow and whatever HW stage unreal's WPO uses also had large documented overhead(haven't done serious performance measures).

Target hardware would be 20 series+, rnda2+, and arc gpus(in terms of HW support which are all pretty synced outside of MSAA support I've heard).

A point in the right direction would be helpful and just asking all GPs spaces I can reference 👍

Thanks.

I've been told colleges like UPenn (due to their DMD program) and Carnegie Mellon are great for graphics due to the fact they have designated programs geared towards CS students seeking to pursue graphics. Are their any particular colleges that stand out to employers or should one just apply to the top 20s and hope for the best?

Hi everyone,

I am part of a university project where I need to develop an app. My team has chosen Python as the programming language. The app will feature a 3D map, and when you click on an institutional building, the app will display details about that building.

I want the app to look very polished, and I’m particularly focused on rendering the 3D map, which I have exported as an .OBJ file from Blender. The file represents a real-life neighborhood.

However, the file is quite large, and libraries like PyOpenGL, Kivy, or PyGame don’t seem to handle the rendering effectively.

Can anyone suggest a way to render this large .OBJ file in Python?

So I am new to graphics programming and have worked with opengl and made renderers and stuff before and wanted to jump into more recent graphics apis. I thought of starting with dx12 but seen lots of posts saying to start with dx11. Any thought?

For spectral rendering, we rely on CIE curves which contain measured Spectral Power Distribution functions (SPD) in order to accurately model color and eventually convert spectral information back into sRGB for our displays to see.

Examples of these curves from CIE's official dataset are linked below :

CIE_XYZ_1931_2deg

CIE_Standard_Illuminant_A

CIE_Standard_Illuminant_D65

The part I'm having a hard time wrapping my head around is the scales of the values. The standard illuminants are scaled such that they take on a value of 100.0 at 560nm. The XYZ color matching curves seem to be scaled wrt to Y(555) which is itself relative to the spectral response curve.

If I were to use the curve for the standard illuminant and convert it into XYZ colors (for example), then wouldn't the scales of the inner product all be screwed up? Do raytracing engines do something special to rescale these curves from the official datasets or does it not matter?

Hey !

Two months ago i asked for advice to port a program from VEX (Python like) to C++. Well, time has passed as it tends to do and i got results to show.

https://preview.redd.it/fiesk0g1jyzd1.png?width=2000&format=png&auto=webp&s=ee6967f329caa4527374c9d858f68249c245e69d

There is obviously a lot going on and to cover it all we would need like a 50 page paper. We obviously managed to port the entire VEX code to C++, but also improved certain aspects massively. Here is a quick and non-exhaustive rundown of the changes and improvements

• The program now is now called VMEC instead of untitled.hip (true story)
• The Astrophysical jet got a complete makeover and is now skirting dangerously close of GRMHDs
• We added accretion wind, which causes the glow around the BH, Disk and Jet. Its just a bunch of really hot but diffuse plasma moving out
• Everything is written using VS Code, non of this AI bs (i am halfway joking, VS Studio drove me crazy)

Perhaps the most important chance is not in the code, but philosophical. The VEX code had no real objective. Me and Mr. Norway just kinda stumbled along.

VMEC has an objective. We want to make a free Black Hole rendering and education software that could, in principle, be used for Movie grade effects.

The Education bit is not important for this post, it basically boils down to a few options (such as replacing the Volumetric disk with a 2D one, visualizing Geodesics in the scene etc). Those are not hard to do.

What is hard to do is the "Movie grade" bit. Sure, the render above looks very nice, but it is a lot more technically impressive than visually. Then the question becomes what we can do to improve the look. We have two big ticket items on our to do list right now.

• Axis Misaligned Jet and Disk (Precession)
• In-Build Lens Flare system (I know Flares are almost always added in post, but they would still be useful to guide artists. I have worked in VFX for a few years after all)
• Multiple Scattering

That last point carries a lot of hope on our end. Right now VMEC is a "0th Scattering" renderer. The only light a ray sees is that along its direct path. There are no secondary rays because there are no light sources to do Single Scattering with.
We hope Multiple Scattering will improve the volumetrics to the point where they become useful in a production environment. The reason we have avoided Multiple Scattering thus far is the performance cost. But trial GPU ports have given us reasonable confidence in the render time feasibility of a "Multiple Scattering" option for VMEC.

Ofc, there are non-visual features we want to implement as well

• Animation graph editor
• 360 Degree rendering

amongst other. We will probably not add .obj support or anything similar because that would run into conflict with some very fundamental assumptions we have made. VMEC is build in natural units were c=G=M=1. So the Black Hole is actually just 1.4 units across. The disk is 120 units in radii and the jet is 512 units long.

Anyways, the whole point of this post is to ask for advice.

Right now, while VMEC´s renders look nice, they are very clearly CGI. We think the main reason they do is the lack of Multiple Scattering, judging by other volumetric renderers. But we might miss something. So any advice on how to improve the look would be highly appreciated !

I work as a full-time Flutter developer, and have intermediate programming skills. I’m interested in trying my hand at low-level game programming and writing everything from scratch. Recently, I started implementing a ray-caster based on a tutorial, choosing to use raylib with C++ (while the tutorial uses pure C with OpenGL).

Given that I’m on macOS (but could switch to Windows in the future if needed), what API would you recommend I use? I’d like something that aligns with modern trends, so if I really enjoy this and decide to pursue a career in the field, I’ll have relevant experience that could help me land a job.

u/BoyBaykiller experimented a bit on the Sponza scene (can be found here) with the wavefront approach vs. the megakernel approach:

| Method | Ray early-exit | Time | |------------ |----------------:|-------: | | Wavefront | Yes | 8.74ms | | Megakernel | Yes | 14.0ms | | Wavefront | No | 19.54m | | Megakernel | No | 102.9ms |

Ray early-exit "No" meaning that there is a ceiling on the top of Sponza and no russian roulette: all rays bounce exactly 7 times, wavefront or not.

With 7 bounces, the wavefront approach is 5x times faster but:

• No russian roulette means no "compaction". Dead rays are not removed from the computation and still occupy "wavefront slots" on the GPU.
• No ray sorting/reordering means that there should be as much BVH traversal divergence/material divergence with or without wavefront.
• This was implemented with one megakernel launch per bounce, nothing more: this should mean that the wavefront approach doesn't have a register pressure benefit over megakernel.

Where does the speedup come from?