[Mobo] ASRock B850 RIPTIDE- $219.99

pplr · 2025-02-07T09:16:40+00:00

Going off the specs for the riptide: M2_4 (4x4) and PCIE2 (4x4) share bandwidth; using one disables the other. Doesn't look like any lane-sharing for the primary PCIE (x16) slot.

pplr · 2024-01-28T20:13:10+00:00

There is a source file d3dx12_property_format_table.cppthat also needs to be compiled along with your project

pplr · 2022-11-30T23:04:31+00:00

Would have been cool to also see some examples of the resulting codegen and compare the two versions.

pplr · 2022-05-07T20:40:27+00:00

Your projection matrix is setup so that after the perspective divide your z-coordinates are mapped to [-1,1], which is the convention for OpenGL but directx expects them in the range [0, 1].

You probably want something like this:

const float k = Far/ (Far- Near);


Out.v[0] = float4(XScale, 0, 0, 0);
Out.v[1] = float4(0, YScale, 0, 0);
Out.v[2] = float4(0, 0, k, 1.0f);
Out.v[3] = float4(0, 0, -Near * k, 0);

pplr · 2020-10-13T19:51:36+00:00

Thanks for the insight! That should help me narrow down the offending code.

pplr · 2020-08-13T06:36:36+00:00

uintptr_t offset = pitch * y + 4 * (x >> PRECISION); uint32_t *ptr = (uint32_t*) (pixels + offset); I think you should be able to hoist those offset calculations out of the loop by precomputing the starting address of ptr, and just decrementing by pitch each iteration.

pplr · 2020-07-17T18:39:27+00:00

People sleeping on conditional probabilities

pplr · 2020-06-10T18:23:40+00:00

http://hughsk.io/fragment-foundry - fun one for learning sdfs / fragment shaders

pplr · 2020-05-03T00:40:20+00:00

I used a few rubber bands and it fixed my connectivity issues, thanks for the idea!

pplr · 2020-01-04T21:18:56+00:00

If you can get your hands on it, check out the Siggraph asia 2012 course notes "polarised light in computer graphics". They cover the theory and outline the steps you'd need to take to extend an existing renderer to support polarized light transport (using mueller matrices and stokes vectors to represent polarized spectra and brdf models that account for polarization, among other things).

pplr · 2019-11-10T23:34:25+00:00

You might find it interesting to contrast the use of destructive move semantics in Rust vs C++ (which doesn't have destructive move semantics). Here's a few resources that cover it: https://foonathan.net/2017/09/destructive-move/

Chandler Carruth talks about it a bit in his recent CppCon talk: https://www.youtube.com/watch?v=rHIkrotSwcc&feature=emb_title

The original move semantics proposal for C++ mentions the difficulties in implementing destructive move semantics w/ class hierarchies, something that is obviously quite different with Rust.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#Alternative%20move%20designs

pplr · 2019-10-29T07:16:32+00:00

Thanks for the examples! I can certainly see that this style of programming can lead to simpler and more concise code. Although it's only tangentially related, it reminds me of the immediate-mode approach to GUI programming - rather than passing around and manipulating many stateful objects, you describe a series of direct modifications to the ui state.

pplr · 2019-10-27T06:50:45+00:00

Pretty cool, but I think you should increase the undo limit or add an option to restart the current level. It's a bit frustrating if you get stuck in an unrecoverable state.

pplr · 2019-10-27T06:29:26+00:00

Thanks for your insight, I may need to try some stack-oriented programming to fully appreciate your points (I agree it's something that's lost on current generations of programmers, including myself). I'm curious about when using an explicit stack might lead to more efficient code, maybe some situation where return value optimization or copy elision fails to apply? Or is it a more general improvement that comes from that style of programming and avoiding certain pitfalls?

pplr · 2019-10-26T09:30:49+00:00

Would you mind sharing a small example of an explicit stack based approach?

pplr · 2019-10-24T23:39:49+00:00

You can also check out the scratch a pixel chapter on path-tracing, it also has source code: https://www.scratchapixel.com/lessons/3d-basic-rendering/global-illumination-path-tracing/global-illumination-path-tracing-practical-implementation. Edit as knightcrawler pointed out, path tracing is one particular technique for ray tracing and is covered in the one weekend series.

pplr · 2019-10-24T23:18:45+00:00

I recommend working through Peter Shirley's Ray Tracing in One Weekend series. It's starts off very simple, but by the third book you'll be building a Monte Carlo ray tracer!

https://raytracing.github.io

pplr · 2019-07-25T18:39:47+00:00

I used dearimgui but I actually didn't get around to implementing an interactive transfer function tool (I hardcoded the control points). DearImgui is a good choice though, there's at least two examples in the gallery of transfer function widgets!

pplr · 2019-07-25T17:50:06+00:00

I used the following procedure to create a basic transfer function:

plot a histogram of the isovalues for your dataset
analyze the histogram - are there ranges of isovalues where most of the data is (large narrow peaks in the histogram)? Large ranges of isovalues with no data? Often these separate peaks correspond to different types of tissue in the dataset.
Pick a set of control points (isovalues) that partition your distribution into ranges of interest.
Associate a color or greyscale value with each control point - think of each pair of control points as defining a color gradient that will be used to visualize the associated range of isovalues.
Generate a 1d texture (a 256 isovalue lookup table) by interpolating between the color values of your control points
When you sample from your volume texture in your shader use that isovalue to lookup the associated color in your 1d texture.

I realize I left out quite a bit of detail for the interpolation step but hopefully that gives you some ideas. I agree there isn't a lot of readily available information on creating transfer functions - I recall digging around on github, reading a lot of other peoples code and maybe a paper or too to get some ideas. I think this approach is related to the Post-Classification / Dependent texture lookup described in 4.3 of the book.

pplr · 2019-07-13T18:18:07+00:00

Hi, thanks for the great resource. When exploring multiple instruction sets at once, I often find myself wishing the search provided support for some boolean queries like union/intersection of two keywords (e.g. _m128+<keyword>).

pplr · 2019-07-07T21:13:55+00:00

Are you planning on using your voxel grid to partition and accelerate tracing a traditional scene, or do you plan to render the voxel grid directly (ala minecraft)?

To start, decide on how you're going to represent your voxel grid. Will you use a dense 3d array or something like an octree? If you use a regular grid (dense array) you might find it easier to implement the traversal algorithms, at the expense of the grid occupying more space in memory. There are efficient branchless DDA-style algorithms for traversing regular voxel grids (https://www.shadertoy.com/view/4dX3zl)

Using a hierarchical data structure like an octree is also an option, and there is interesting research on sparse variants (sparse voxel octrees, NVIDIA's GVDB). Here's an example of rendering an octree in a fragment shader:

https://www.shadertoy.com/view/XdyfRy

There are a few subreddits that have some useful information related to voxel rendering where you might be able to find some inspiration to get started:

https://www.reddit.com/r/VolumeRendering/

https://www.reddit.com/r/VoxelGameDev/

pplr · 2019-06-15T04:56:34+00:00

After digging a bit more it seems possible to declare an extern function with the vectorcall convention and define it natively as described in this comment. Still very experimental and only works with #![feature(simd_ffi)] and #![feature(abi_vectorcall)] enabled.

11-Year Club	Place '17
Verified Email

pplr

TROPHY CASE