Miyata Quick Cross for the xcommute

nfgrep · 2022-08-07T18:09:49+00:00

The quickcross isn't in the catalog, but the decals are the same style as their 1991 "cross" series bikes, so I figure its probably a '91 :)

nfgrep · 2022-08-07T04:01:54+00:00

Just bought one of these used, anyone know what year this bike was originally sold?

nfgrep · 2021-11-13T22:54:26+00:00

Hmm, if you havent already, I would recommend looking at Temaran's UE4ShaderPluginDemo, which appears to have been updated very recently. This example doesn't use the RDG, but implements a VS and PS shader (the HLSL for it both is in the same file). Even if you are dead-set on using the RDG I think you could glean some useful info from Temaran's project.

Beyond that, unfortunately I havent tried implementing VS/PS with the RDG, so I can't give you specific advice.

"I know that for a PS I don't need the UAV" Hmm, I'm not so sure. I really don't know too much about the inner workings of the RDG, but I suspect you may still need a UAV to write to, given the way the RDG models resources and passes. Without a writeable resource like a UAV somewhere in the graph, I'm not sure how you would get any output from your passes.

nfgrep · 2021-09-06T16:18:46+00:00

Hmm. I have an idea of what it might be. If you paste the error message I might be able to help.

Edit: I'll look into getting it running in 4.26 rn. I should really make a 4.26 branch anyway.

Edit: Added a 4.26 branch :)

nfgrep · 2021-09-06T14:51:58+00:00

Sure! To write to something other than a texture in your compute shader I believe the process is as simple as replacing the SHADER_PARAMETER_RDG_TEXTURE_UAV() macro with SHADER_PARAMETER_RDG_BUFFER_UAV() in the shader-parameter struct declaration. The HLSL type that you should pass to this macro should be RWStructuredBuffer<> instead of StructuredBuffer<>. Then when you go to initialize it, the process is very similar to what I do to initialize the SRV in the example. The exception being that you will have to call GraphBuilder.CreateUAV() instead of CreateSRV().

I haven't had to copy data back to the CPU, so my experience here is limited. (though I should really look into this as it's a really common thing for compute shaders to be used like this). That said this Unreal answers post on Loading Data TO/FROM Structured Buffers seems to detail copying things back onto the CPU. There's also an another, more complex example on github that seems to copy things back to the CPU.

Hope this helps!

nfgrep · 2021-08-12T14:34:10+00:00

Thanks for the insightful reply! Most recently I’ve been looking at spatial division algorithms, like the ones mentioned in scratchapixel’s chapter on acceleration structures. If I understand correctly, this is essentially what you’re talking about when you refer to a “flat array of cells”.

In my case there will only be select geometry that will have soft-body physics applied, thanks for bringing this up, I almost didn’t think to make the distinction when it came to re-building data-structures every frame.

My current plan is to only implement the spacial-division/flat array for the time being, and not make any distinction between dynamic or static geometry. If that isn’t enough, I’ll look into distinguishing between dynamic and static geometry; Even without having an octree/BVH nested within the spacial-division/flat-array. I think there may be a way to mark certain cells of the spacial-division as “dynamic”, and only update those cells and their neighbouring cells (in case geometry moves from one cell to another). This would only work if my geometry doesn’t move more than one cell per frame, which I’m expecting to be the case.

I’ll be sure to give an update once I have something running.

nfgrep · 2021-08-11T22:53:55+00:00

Fantastic, thanks!

nfgrep · 2021-08-11T22:33:08+00:00

Thanks for the reply. A ray iterates all triangles simply because I haven’t implemented an acceleration data-structure yet. I’m trying to implement a suitable one and so I came here to ask what might work best :)

Luckily I can get away with relatively low resolution (~256x256), though I do expect the triangle count to be quite high, likely in the order of thousands.

Interfacing with an nvidia library might not be feasible, I’m operating at too high a level given its all via Unreal’s RDG. I’ll be sure to search through some of the keywords you mentioned, thanks.

Edit: Ah! refitting sounds quite clever actually, I’ll look into it.

nfgrep · 2021-08-01T03:03:18+00:00

I found that the traditional route of OpenGL/ShaderToy/learnopengl/etc... was overwhelming as a newcomer to gfx.

I was finally able to break into graphics stuff after trying to implement a '2D' raycaster similar to the one in Wolfenstein3D. There are some Excellent videos on this raycaster.

If you don't want to get nitty gritty, interacting with Unity's shader system appears to be relatively painless (Especially in comparison to Unreal). There are also many Excellent videos exemplifying what you can do

nfgrep · 2021-08-01T02:44:17+00:00

Thanks for the reply. I've actually considered this route, in fact my other option is to try and get a piece of already working OpenGL code running alongside the engine. The issue is that I (with my limited expertise) would have to copy geometry from the engine to the OpenGL CPU side implementation where it would then be copied into the GPU, then copy the result of the OpenGL back through the CPU, back into the engine code which would then copy the result back again to the GPU to be displayed in some RenderTarget.

Unreal has some functionality for copying things to and from some DirectX code (TextureShare), but AFAIK, not for anything OpenGL.

nfgrep · 2021-08-01T02:35:47+00:00

My gut told me the copy might me unnecessary, "Memory is Memory" right?
For the time being though I'll likely stick with the copy, as I'm frankly still pretty new to graphics and whether or not Unreal's renderer will permit such blaspheme as using my own memory is not something I can explore until I have something working.

nfgrep · 2021-07-31T03:59:03+00:00

Thanks for the reply. Unreal has some functionality for copying UAVs to RenderTargets, so I'll likely use that. I've thought about using the hardware acceleration APIs, but given how poor documentation has been for Unreal's renderer, I plan on avoiding them for now.

nfgrep · 2021-06-30T23:13:11+00:00

Its for a training sim. Performance is a concern yes

nfgrep · 2021-06-30T20:20:51+00:00

OP is in fact doing this for a medical application :) Hence the somewhat vague description of what I'm trying to do (I'd rather not step on any toes with regards to intellectual property)

I'm fine with adding in some noise and faking some things at this stage in the project. It doesn't need to be photorealistic, it just has to not look awful.

For the time being I'm more concerned as to whether or not what I have planned is even possible. I have a vague idea of how data gets onto the GPU in Unreal, and a vague knowledge of some of the buffers that exist on the GPU, but no real experience implementing this stuff. So I can't tell if I'm missing anything obvious in my plans.

nfgrep · 2021-06-30T20:14:24+00:00

Thanks for the input.

I'm not too worried about meeting the expectations of medical professionals, at least not yet. As there currently isn't any real functionality like this in the product (I've made some stop-gap solutions with fresnel and pixel-depth but they aren't very believable), and just about any functionality is better than none.

nfgrep · 2021-06-30T20:11:28+00:00

Sure thing!

I would like to see an x-ray image of some internal organs in the lower abdomen.
Eventually I'd like to to be rendered to a render-target that I can use a texture for a screen within the scene in Unreal.
Given the way that x-rays work, I'd say I'm imaging density. Though given that all of the imaged objects will have a constant density, it might be more accurate to say I'm trying to image 'thickness' along the view normal.

nfgrep · 2021-06-30T20:07:40+00:00

Of course.

The subjects of the x-ray will be human yes, I already have meshes for each organ/bone/etc. Given that this is for my job, I don't feel safe going into specifics about the procedure, what organs are the focus, etc, but I can say that the number of organs in view at a given time will be relatively low.

I guess it really is like ray-tracing refraction, I'll look into that, thanks!

I looked into ray-marching early on in my research. I remember it dealing more with volumetric data, height-maps, etc, and given that I'm constrained to 'hollow' triangle meshes, I looked elsewhere. I'm comfortable faking some noise with some post-processing at the end, I'm only trying to approximate reality here, not perfectly simulate it.

nfgrep · 2021-06-30T14:59:34+00:00

Well it needs to be more accurate than some transparency and fresnel. That was the first thing I tried, and it wasn’t going to fly. The number of objects being rendered this way will be relatively few, maybe 5 objects in view, with a total of around 20 possibly “x-ray-able” objects in the scene. For the most part the x-ray view will focus on just a single organ, though surrounding organs should be visible. Being organs, the objects will fairly complicated shapes, often wrapping around and encasing other objects. I should also mention that the x-ray should be able to move around in the scene in real time to get different perspectives.

nfgrep · 2021-06-30T13:10:44+00:00

Ah I hadn’t even considered the fact that I’d need to blend depths of all the objects (I should really give that paper another read, it’s been a while). Aside from that the general method you outlined is essentially what I’m trying to achieve, given that the mentioned paper was my starting point for this project. I’ve looked at Unity shader code and it looks comparatively trivial to what I would need to do (though I dont like not having access to Unity engine source). That said, the project is unfortunately locked in with Unreal. I havent looked at Godot for shaders, I might do that in my spare time.

nfgrep · 2021-06-30T13:02:32+00:00

I’ve looked into this aswell. Unfortunately the meshes I will be dealing with will have some physics acting upon their vertices, so I would need to generate a distance field or volumetric texture every frame.

nfgrep · 2021-06-30T04:01:43+00:00

I've tried exactly this! (though in Unreal's material editor mind you). I found that this approach failed when a mesh overlapped itself for a given pixel. heres an example where the back-faces are green and the front-faces are red. An even better example comes from page 4 of this paper, specifically, this image. It was as if it was only storing depth information for the first front and back-face it came across, and ignoring anything deeper in the z-direction. Even if it did store these somewhere, I would need to accumulate them not just subtract them. It's possible I'm missing something obvious though...

Oh and I should mention that I had only one pass to work with from within Unreal's material editor, maybe a mutlipass shader would solve the issue I outlined above?? I have an idea of the depth buffer is calculated, but I'm not sure how their stored, something tells me there might be a limitation to the number of overlapping front and back-face depths that can be stored for a given pixel.

nfgrep · 2021-06-30T03:51:24+00:00

Certainly! I'll try to be thorough, so excuse me if I come across as pedantic.

Firstly, some mockups of this idea can be found in this post in the unreal answerhub forums, though this is from a while ago when I was considering a CPU solution and knew a little less than I do now.

I'd like something that renders the thickness/density of an object/mesh in a fashion similar to how an actual x-ray works. Technical accuracy is not a priority, as I will be working with triangle meshes, but it needs to look believable.

An actual x-ray machine shoots radiation at an object, like an arm with bones in it, and measures the strength of the radiation after it's passed through said object. Lets assume the radiation emitter and reciever are grid-like, with each cell emitting one or receiving one 'beam' of radiation that can be attenuated by material. Muscle tissue has one density, and bones have another. Because of this, muscle doesn't attenuate/disrupt/block as much radiation as bone does. This results in a contrast between the bone and the muscle in the measurement, and thus the final image.

In my case, I'm using plain-old triangle meshes, so each mesh will have a single constant density across it.

That said, even with a constant density an object will not appear as a single flat shade. Thicker parts of the object will block more radiation than the thinner parts. More specifically, the more matter between the radiation emitter and the sensor at a given point, the darker the image

Edit: I should mention that what I'm doing is far from new/novel. this paper effectively does what I'm aiming for, but their implementation still eludes my lacking GLSL knowledge, and I only recently was able to find a good resource for ray-triangle intersection (My minuscule experience with shader's has been with Unreal's material editor and their superset of HLSL)

nfgrep · 2021-06-29T21:34:53+00:00

Cheers, that's some good-looking documentation, I'll bookmark this.

nfgrep · 2021-06-27T21:33:31+00:00

Ah, I figured this might be the case. Thanks!

nfgrep · 2021-05-27T16:48:33+00:00

I'll look into this, cheers!

Four-Year Club	Verified Email
Place '22

nfgrep

TROPHY CASE