#Bioshock (Original Release)

972 messages · Page 1 of 1 (latest)

whole gull
#

It did freeze, but I got in and was able to walk around for a few minutes. Background audio is still playing though

#

It started working again after selecting this texture. It freezes again if I deselect it

#

As a UI texture

#

It’s working! Laggy but it is haha

drifting temple
#

how did you bypass the new game plane crash?

restive current
#

This looks like it’s just being rasterized. Try adding dxvk.hud = rtx to dxvk.conf

whole gull
#

Do you mean the Rtx.conf?

#

I thought rasterization wouldn’t work if it was running with remix? Doesn’t it override rasterization functionality entirely?

#

And the plane crash wasn’t an issue for me

daring iron
#

Try turning in debug from the rtx menu. It's on the first window

#

If it's path tracing it'll render it all red and stuff depending on your debug view mode

#

This looks rasterized though. Path tracing makes everything look crazy and weird until you set it up proper

whole gull
#

Still tinkering with it to see if I can get it to ray trace, it seems to recover from freezes after disabling v sync in game though.

daring iron
#

Could you quickly try turning on debug though?

whole gull
#

Yeah it didn’t show anything

#

Do you know what these textures are for? They seem to have a particular effect of the freezing

IMG_1062.jpg
daring iron
#

Cheers

whole gull
#

Is it for lighting?

daring iron
#

Well that's a bummer

#

Some sort of packed light map if I had to guess

whole gull
#

Hmm how should that be categorized as? The game has its own global illumination system, so maybe messing with these will fix it

daring iron
#

If debug isn't changing the render output it's rasterized. Check your log and search for a line like "can't find camera"

#

That's the final nail in the coffin for getting this to work with BioShock

whole gull
#

Nvremixbridge?

#

No complaints about a camera

daring iron
#

In the root game folder, where you put the trex one you have two log files. It's one of them

whole gull
#

😦

#

Couldn’t that be from the main menu tho?

daring iron
#

Sorry mate, that's the death message

#

As far as I understand it

whole gull
#

Why wouldn’t it be able to find the camera?

daring iron
#

Not sure. Just the message you get when it won't work. Had the same with cod4

drifting temple
#

yea i was curious why no crash now i have my answer

whole gull
#

This is unacceptable lol there must be a way 😂 I’m gonna look through the modding community, there oughta be someone who modified the camera system in the past 2 decades lol

real stone
#

Rip

whole gull
#

So disabling “capture vetices from shaders” made it freeze. I saw somewhere in the discord threads that this helps fix the vertice shader capture?

drifting temple
#

dont forget to add -dx9 to the command line on the bioshock shortcut so it does not launch the other version

whole gull
#

*camera issue

#

It’s there

drifting temple
#

k

#

#general-remix message i remember now, this as far as i got

#

may

whole gull
#

Yea I’m farther than that

drifting temple
#

save game?

#

i crashed on the flight sequence

#

but this was remix 1.1 back then

#

i wonder

real stone
#

It's not about the camera system. It's something completely else

#

Remix isn't able to find the gamera data from the data that's moving between the CPU and GPU

#

No mod can fix it

whole gull
#

I think the camera message may be from booting up the game since the vertex shaders option does have an effect. If it was rasterizing entirely, I don’t think the remix settings would freeze it up ? Maybe I’m wrong. I refuse to believe it won’t work lol

#

The bioshock config file is super configurable. I will find a way 😂

drifting temple
#

bioshock has lightmap configs in the ini's

#

just saw them

whole gull
#

Hmm. It seems like the game keeps overwriting the config though

drifting temple
#

you need to change the original one

#

i tried to disable the lightmaps now the game wont run lol

whole gull
#

What did you set it to?

drifting temple
#

tried erasing normal after 2 lightmap settings and it crashed

languid totem
#

Anyone had any luck with this recently?

warped swan
languid totem
#

Darn, maybe down the line rtx remix will get updates to help get this rolling. It'd be beautiful with raytracing

calm marlin
#

@whole gull for the love of god, use snipping tool for screenshots (it's installed on all windows versins) and record gameplay with obs

fickle moon
#

Bioshock (Original Release)

pallid cedar
#

any other launch options?

gaunt quiver
#

anyone tried it in 0.4?

languid totem
#

This game has so many folders, I forgot how I installed remix into this one 💀

mild herald
#

I can doublecheck when I get home worksonmymachine
(To be clear, worksonmymachine is mostly right, it hooks and sees textures, but it doesn't render the game with raytracing enabled, but it plays sounds, my assumption is it is a little confused about the render target)

languid totem
#

Yeah I had similar results with bioshock 2, I should've documented a quickstart guide when I had it running lol

mild herald
#

Ok coolio:

I have a test save at the Bathysphere juuust before you enter Rapture proper. I recomend you make a test save before setting up Remix if you haven't already.

Put d3d9.dll and .trex/.. in ...\Bioshock\Builds\Release\ folder next to Bioshock.exe

Create a shortcut to Bioshock.exe (can be done on Windows via the right-click menu (or shift+right click menu on Windows 11)) and for the following target parameters:

  • At least -dx9 to force DirectX9 and I also use -nointro (with one space separation) just to help get into the game a little faster for testing.

Settings are stored under C:\Users\{USERNAME}\AppData\Roaming\Bioshock\ (where {USERNAME} is your log in name)
I swear I had to do something to Bioshock.ini and if I remember what it was I'll edit it in here 😂

I recommend using the debugoptimised version of Remix so you get the toggle at the top of the Remix menu to enable or disable raytracing.
I also recommend opening the remix menu the instant after you click continue on the main menu. I've had issues opening it later if the load menu gets stuck.

#

One oddity is save games are actually stored under ../{USERNAME}/Documents/Bioshock/SaveGames/ and not in the Appdata directory

languid totem
#

Was hoping it'd somehow get remix to render, but no dice.

mild herald
#

I remember messing about with this as well, but frustratingly (at least for the time being) I can either get it to show a raster image, or "raytrace" but show no image at all.

rapid cargo
#

I've been working on a bioshock compatibility mod on the side

#

apologies for the flat materials, working through a instancing problem

languid totem
#

watbulb the goat strikes again PoggersHype

rapid cargo
#

its honestly a miracle this game even rendered in the first place properly. buffer overflows all the time when doing memcpy's into vertex buffers.

#

apitrace is like uhhh, are you sure this is right? (and of course crashes)

mental dome
#

peak…

rapid cargo
#

and yeah tons of shaders in this game, I could never make it fixed function. I've been mostly making the existing shaders compatible

rapid cargo
#

instancing fixed

#

uhh, epilepsy / seizure warning

quiet talon
#

Spaghetti code

rapid cargo
#

it doesn't help that every instance in the world has floating precision issues too, like every object every frame moves by 0.000001 type stuff. terrible

quiet talon
#

Yikers

rapid cargo
#

they also redraw the geometry 4 times

#

in some cases

#

most of it is for texture staging. they waste a lot of drawcalls on stuff, mostly a product of UE2.5 garbo optimizations

#

I'll start on the new thread soon, need to make a pretty thumbnail, I guess

#

I do not look forward to making water work properly in this game. maybe fog + running slang shaders on the remix side for el agua

#

Resting water could probably be done with texture replacement with key framed sprites (to inhibit/cause motion)

rapid cargo
hard shale
#

Yo that's insane

#

I thought there was no hope for bioshock in rtx

#

Please keep at it!!

rapid cargo
#

I'll try!

real stone
rapid cargo
#

the video or the environment?

#

I haven't replaced or added any lights yet

#

nornally in game. no, there's several emissives, but it is a dark room

real stone
rapid cargo
#

oh weird, maybe an encoding thing? it loads on my phone

#

discord has been having alot of problems with video lately idk why, lots of weird paused videos an shit

real stone
#

I'll check it on PC later then

shut lichen
shut lichen
real stone
#

Discord on Android is straight garbage

shut lichen
#

Aye, it's true

quiet talon
real stone
#

The video player bugs out every 3 bideos

quiet talon
real stone
#

Nvm as soon as I hit play it dies

Screenshot_20241127_184308_Discord.png
shut lichen
#

What phone? I'm on a Zenfone 9 and it rarely breaks. The changes to UX are ass though

real stone
#

It's a budget phone

shut lichen
real stone
quiet talon
real stone
rapid cargo
#

classic bethesda

image.png
#

"they'll never notice"

shut lichen
#

@rapid cargo if you get it in a fairly stable state, lemme take a stab at one of the common env textures 👍

rapid cargo
#

sure 👍

#

@shut lichen sorry for the random question, but do you know what the "attach light to texture" option does (when selecting texture category)? I figured maybe you might know.

#

I mean maybe it attaches a light to texture ... but kinda confusing figuring out how?

shut lichen
#

This is unique to the runtime, often times things you'll want to attach lights to like particles will have unstable mesh hashes so you can't do it in the Remix toolkit.

rapid cargo
#

oh okay cool, im going to need to use that for now, since this game also rotates the world, and remix doesn't know how to handle that, so placing a light will not stay correctly until I do some more transform reverse engineering to bind a light to a object position.

#

thx for the info

rapid cargo
rapid cargo
rapid cargo
#

add light to texture doesn't work when world transforms are used/always changing Q_Q. thankfully there's enough fixtures on the maps to do emissive and emissive masks. kinda sucks though. MarkPlsFix

rapture_gates_progress_3.png
rapid cargo
#

@honest badger is it in theory possible to port a material shader from omniverse, such as the perlin noise water shader, and add it as a custom .mdl and .usda "Look", which can then be applied to material or mesh instances?

#

I tried for a little bit and I think it might work? but im not sure. for reference this is my .mdl and .usda look (made some modifications to the .usda to conform it to remix):
the green reef material uses the perlinwave mdl. (there is an option for it to animate, but its optional)

📎 Water_Ocean_Green_Reef.usda 📎 Water_Blue_Ocean_Perlinwaves.mdl
#

cool that I can just distribute these according to nvidia copyright in the mdl file

#

if it is not possible to do it this way, can you think of any ways in-which I can run a shader on the remix side on a certain material or mesh? unfortunately not familiar with that aspect of the code

honest badger
# rapid cargo <@617500777191047168> is it in theory possible to port a material shader from om...

Using MDL to drive USD properties is easy - it's very much how Omniverse USD Composer is designed to operate, and we built the Remix Toolkit on top of all of those utilities.

The problem comes with the Remix renderer / runtime. Implementing the full scope of MDL is very expensive on the GPU. Remix's MDLs are primarily there as a way to define the parameters that our actual hand-written shader code uses.

rapid cargo
#

Okay, thanks. I figured there was a little more to it, so I stopped before wasting a whole bunch of time. There's so many kinds of different ones in omniverse, but I noticed remix uses very few so I was wondering if there was more to the implementation.

#

So I'm guessing the native route is slangh shaders, is that what the live shader edit mode is for?

#

and where do those go?

rich dawn
#

@rapid cargo so umm, can you let me know how this works and what's the current status

rapid cargo
#

current status: not ready
how it works: we ignore draw calls that are used by shaders which are deemed too complex to handle, and either recreate them or competely discard them. We only need geometry and normals / UV for the most part. plus some engine fiddling

#

also ignore samplers for specular and lightmaps, etc

#

stages, etc

mental dome
#

Throwing all complex shaders in an on fire dumpster

rapid cargo
#

yeah pretty much. the technique could actually work for many games, but its luck based. all it takes is one shader to ruin your day with some type of shit

#

this is the product of spending a couple weeks staring into the matrix of PIX until I figured out all the drawcalls that actually matter

rich dawn
rapid cargo
#

yes

#

I need to fix some kind of specular highlighting geom bug, but for the most part its pretty stable, like 85%

rich dawn
#

alr bro, im lowkey interested in Bioshock, if it works well enough with just hooking remix etc do let me know. I'll update the compatibility listing

rapid cargo
#

massive caveat: you cannot place lights using the runtime because remix does not know how to deal with non FF games which rotate the world and view. So you need to get dirty and creative with emissives and emissive masks until I dig more into the game logic and reverse the drawcall transforms

#

sure, I will make a new thread later today or tomorrow

#

I want to have this compatibility mod finished for atleast the first chapter or two by christmas, i'll probably put a build up somewhere in the next few days for beta testers. will take a week or two to cleanup code and stuff, plus im going away next week (for an open source release)

#

if you want the runtime light problem fixed yell at nvidia 🤷‍♂️

rich dawn
#

how does it look like when you take a capture and load it in the toolkit

rapid cargo
#

hit and miss, not sure why. works better if baked transforms are captured. sometimes it captures everything, sometimes its a vertex explosion. in any case not a super big deal, just take three captures for every normal capture, and you should have captured almost everything in front of you

#

culling needs to be disabled for this game tho big time, so im working on that too. there is a CullDistance setting, but it doesn't affect the FOV of the cull frustum (or w/e they use), so if I can increase the frustum FOV there should be no odd culling anymore. Just setting the player camera FOV isn't enough

#

somewhat proper capture

image.png
#

almost every texture has baked lighting, but it can be trivially removed

rapid cargo
#

dude needs to be replaced so bad

image.png
#

chunky af

#

I love how the hanging lights clip into the flag too. never noticed that, but I just double checked on Xbox360 and sure enough

#

🙃

languid totem
#

Is a man not entitled to the sweat of his browww Thinkge

rapid cargo
#

lol

mild herald
#

HMU if / when you need more people on this.
Id love to contribute to Bioshock asset replacement; and if you ever have the time Id love to bend your ear a bit about reverse engineering and c buildchains (my Oblivion work is stalled on some linking issues).
I have been struggling (but part of that is self-inflicted) but of course no obligation what-so-ever ❤️ happy just to lend a hand with materials and meshes!

rapid cargo
# mild herald HMU if / when you need more people on this. Id love to contribute to Bioshock as...

Hi 👋. Sorry I missed your message. Sure, I'll let you know when it stabilizes more, currently just working my way through the game and fixing as much as I can before letting people do that, or else it would be a waste of time as everything would need to be retagged. Or some idiot will post a video on youtube.
Everything seems to be going okay for the most part, minus a issue with LODs being forced to a lower level once the player moves through a different portal.

rapid cargo
rapid cargo
#

@languid totem what software are you using for your PBR mods these days? I keep forgetting what there all is / people use. Also do you have any recommendations for materials repositories? Currently I just use NVIDIA's VMaterials 2, but I don't know if they are open source materials. They might be since they are essentially MDL examples. I need to generate some basic materials to mark replacement objects.

#

I could use the AI tools, but those don't work on 2xxx series

shut lichen
rapid cargo
#

Okay. Yeah I’m sort of going through and looking at ComfyUI and things. I don’t see anything that says if there’s a minimum card requirement tho. I can’t run any of this stuff on a lower end card, right?

shut lichen
#

PBRify scales to lower end cards I'm pretty sure. @fickle moon ?

#

dunno when she'll come around, but she made PBRify

rapid cargo
#

Do you have any recommendations for open source materials that already have been created?

#

Like say I want a marble.

shut lichen
#

freePBR, AmbientCG, PolyHaven are all options, each with their share of hits and misses but largely they work well

rapid cargo
#

Thx for the suggestions

shut lichen
#

from ambientCG

#

depending on how "generic" the texture being replaced is, you can get some really high quality replacements through this stuff

rapid cargo
#

Well that should probably be more than enough to work with

#

For now at least

#

That’s so cool they are all free and have different formats and resolutions

shut lichen
#

for sure. If you're curious I threw some free materials onto Black Ops 1 as a proof of concept here #1152352915781058580 message. I would just copy paste but the images are loading super slowly for whatever reason

#

it was a touch tricky to get decent matches but it worked for a test

#

the carpet in particular is a really sweet before and after

rapid cargo
#

Wow yeah looks great. Trying to find suitable rock and brick materials for now, since I’m not capturing any normals or UV (until I fix many, many issues with intercepting them from the shaders.).

Most of what the character is looking at is rock, but with the current default albedo and weird SRGB texture it all has a flat sheen so it makes it a little difficult to test lighting characteristics. From my initial testing a scene becomes nominally brighter in most games with the simple addition of PBR textures due to the drastic change in surface light interaction.

shut lichen
#

in the black ops example it actually got quite a bit darker. It's really fascinating to see, shows we take modern PBR for granted I think

rapid cargo
#

Yeah I suppose it would depend on the setting and the properties of the initial textures and surrounding ones

#

@shut lichen Since I see you use substance a lot (I’ve never used it). Would you say once you know how to you can create whatever surface you envision? Or is it still pretty tough? Do you use substance for that?

shut lichen
#

for tiling environment textures I use instaMAT, I started using Substance Painter for props specifically. instaMAT is similar to Substance Designer in that it uses a node graph to build textures procedurally. I'd say for the most part once you've learned the basics you can make a good 80% of what you'd wanna make at least

#

from there the hardest part isn't making the texture, rather making the texture realistic. So getting the roughness right on a certain material for instance. For that I try and get feedback from others to tune in the final stages. Also getting natural looking imperfections has more of a science to it relating to knowing how real world materials degrade. That's another thing I ask for help with

#

btw instaMAT is free so no harm in giving that a shot if you want. It comes stocked with a whole bunch of procedural textures that have different parameters you can customize so you aren't stuck with an exact texture like many open source assets will be

rapid cargo
#

Ah okay. That’s another one I’ll have to read up on (InstaMAT). Thanks 🙏.

If you are trying to figure out what roughness or metalic amount is correct could you use the toolkit to checkout the values during render time? Or do you kinda need to go back and forth between software and toolkit (like A/B comparison testing)

shut lichen
#

lemme see if I can't get a quick example

rapid cargo
#

Ahhh that makes way more sense.

#

Good to know the material properties are faithful between render engines t

#

That would be such a pain in the ass if not

shut lichen
#
  1. How it looks in Substance Painter
  2. Remix in a bright environment
image.png image.png
#
  1. Remix in a dark environment
rapid cargo
#

Oh wow. That’s quite spot on.

shut lichen
#

small disclaimer that the Painter representation is in 4K, the Remix examples are 1K so some precision is lost. Fine for such a small object

#

but yeah the texturing software has very flat lighting typically. You get a very neutral representation for the most part. Once you get it in action that's when you see all the differences in various light conditions

rapid cargo
#

Let’s say you wanted to make the red button emissive. Could you do that? How would you do that? Currently the only way I know how is to make a emissive mask as a negative of all the areas but the button (if that makes sense)

shut lichen
rapid cargo
#

Oh shit no way

shut lichen
#

this is the emissive map

sm_thermalDetonatorRemix_ThermalDetonator_Emissive_sRGB.png
#

it's quite bland lol

rapid cargo
#

I do all that manually right now 😂😂

shut lichen
#

actually I think that image is messed up, circle should be not janky like that. But it works in-game so shruge

languid totem
#

Common Auto W clappypepe

rapid cargo
#

Ah okay good to know, thanks. I was wondering which one worked better on what cards

languid totem
rapid cargo
#

@honest badger I desperately need a way to selectively disable alpha blending for specific textures. Do you know if this is possible through the runtime? Really unsure what's going on, looking at pix it doesn't seem like its doing anything unexpected. A few things really need the blending. So the easiest way I can see forward is to ignore the operation on draw calls that use alpha blending when the bugged material is set for that call. But what do you think? Attached video shows the disappearing bug.

#

stupid discord, apparently the video is paused 🙄

#

hopefully that worked

shut lichen
rapid cargo
#

hmm yeah, the problem is I need to explicitly disable the blending step, not alpha in general

#

I thought that would have worked as a short term fix too, but apparently not for these stairs

#

🤷‍♂️

shut lichen
#

I think under a section just called alpha blending

rapid cargo
#

what makes it even weirder, is if I override the drawcall to force:

  if (State == D3DRS_ALPHABLENDENABLE) {
    Value = FALSE;
  }

it still happens, so it might be a remix bug.

rapid cargo
#

but that does it for everything

shut lichen
#

oops. On a slow connection atm so couldn't check the vid

rapid cargo
#

np. I could probably solve this on my end by hashing all the texture pointers, then disabling the op when detected. but if its a useful feature to have in the runtime I'd rather just do a PR for the feature. similar to ignore texture alpha

#

but even that might not work if the above override I tried doesn't seem to work as expected (in the code). I need to read up more on alpha blending

fickle moon
#

works perfectly now even on very low end cards

#

you could use it on a 1060 most likely

rapid cargo
#

oh nice 👍

rich dawn
fickle moon
#

well, the fact that there's a 1060 3 GB... 😛

#

but yeah, sorry lol

#

with changing of the tile size in chaiNNer it can run on even lower end cards though

#

also, skurtyy uses pbrfusion now instead of PBRify i think

honest badger
rapid cargo
#

I mean I don't know either. if you set ignore alpha it doesn't do anything 🤷‍♂️

#

on that texture

honest badger
#

okay, so setting the texture to the ignore alpha categories doesn't seem to do anything for you?

#

and the behavior is that when alpha blending is enabled, several parts of the mesh just disappear?

#

Have you tried disabling OMMs?

rapid cargo
honest badger
#

the category right about what you were clicking - opacity micromap ignore texture - please try that

rapid cargo
#

okay will do

honest badger
#

(not confident, just eliminating possibilities

#

tho as a note, with material replacement it's possible to change the alpha blend settings, which could probably fix this too

rapid cargo
rapid cargo
#

oops meant to reply to message below

#

I'll just have to make alot of captures

#

oh, its not obvious from the video I just shared, but the geometry is still invisible when I disable alpha blending, because I need to move my camera for it to redraw it

#

(I dont know why)

honest badger
# rapid cargo I'll just have to make alot of captures

It should be a material replacement, not a mesh replacement. I presume you intend to replace all the materials already 😛

That being said, I'm not actually sure this is even a material property... the way things appear / disappear as you move around means there's probably something else going on...

#

Does this game use light maps or anything like that? I see some normal maps in the texture list...

#

you may need to ignore those draw calls for the normal draws to work correctly

rapid cargo
#

it only happens in that area, which is a portal area between two parts of the level. I already ignore all lightmap and specular draw calls

#

with it off, its just culling really and some slight hitches

#

some noise stuff cuz I was on performance and no neecache

honest badger
#

Your videos are so dark I can hardly make out what's actually going on in them 😦

The fact that different parts of the staircase seem to be missing at different times makes me think that this has more to do with draw call order or something like that, and less to do with the actual alpha blending

rapid cargo
#

I can record it again, but I am trying to show you the staircase does not go missing with blending disabled

#

its very clear

honest badger
#

as in multiple draw calls get routed to the same mesh, and depending on the order of those calls we either draw using the stair material, or some detail / dust / whatever mateiral

rapid cargo
#

I mean I can break out the entire call trace for the mesh from pix if it helps debug, its nothing crazy

honest badger
#

well, the fact the rendering doesn't instantly change when you disable that is also suspicious

#

does the same geometry get re-used with a different texture / shader later on?

rapid cargo
#

I think so, there's multiples of those staircases in the level I believe

#

possibly with different textures

honest badger
#

I mean multiple times in the same location

#

some games might draw the same mesh+transform multiple times. the later draws would be mostly transparent, just adding a layer of grunge or dust on top of the original

#

sometimes they do that with crazy alpha / color blend settings

rapid cargo
#

possibly, that was one of the things I had to stop, the game draws geometry without textures bound to it multiple times (which are visually useless 99% of the time)

#

I can check for the staircase geom specifically

honest badger
#

just based on the behavior I was seeing, it seemed like something along those lines was more likely

rapid cargo
#

oh

#

yeah

#

its drawing it twice I think

honest badger
#

are both draws using the same texture?

rapid cargo
#

I think so ... but like you said its doing some whaacky alpha color blending stuff on the second call

#

which comes after

#

so that makes sense 🙃

honest badger
#

then yeah, just ignore that second texture 🙂

rapid cargo
#

it doesn't show up tho in remix Confused, only in PIX 👀

honest badger
#

Does the texture show up in the texture list on the right? it may not be selectable in the viewport

rapid cargo
#

I think its buried somewhere in the texture list

#

but its very very long

#

😂

honest badger
#

You can make the remix window wider and I think you can make the thumbnails smaller

#

or you can just take a capture, pop that open in a non-remix usd viewer, and you should be able to select that mesh and see what material hash it uses. Then manually add that to the rtx.conf

rapid cargo
#

@honest badger huh, setting it to world space UI background instantly fixed it

#

I'll take it

#

I actually feel really stupid now for not just trying that

honest badger
rapid cargo
#

the primary one

honest badger
#

not sure if it will still get correct lighting if you set the primary to world space UI, but if it works 🤷‍♂️

rapid cargo
#

thanks for the rubber ducking 🤝

rapid cargo
#

welp, I ended up implementing a full blown material hashing system anyways :P. I couldn't figure out how to disable alpha blending on certain things from just the toolkit captures, especially since captures are currently quite flakey. I also couldn't disable it on the skysphere texture.

#

was probably a useful excercise anyways since it uncovered some bugs where the engine seems to be re-creating the same texture multiple times per frame when moving through certain areas, while using the same handle (may not be a bug persay, but its a perf hog)

[MAGOS] WARN: collision detected on texture ptr: 299B0C10
[MAGOS] WARN: tex hash: 112148190
[MAGOS] WARN: collision detected on texture ptr: 299B0890
[MAGOS] WARN: tex hash: 3774354147
[MAGOS] WARN: collision detected on texture ptr: 299B13F0
[MAGOS] WARN: tex hash: 3900075402
[MAGOS] WARN: collision detected on texture ptr: 299B14D0
[MAGOS] WARN: tex hash: 927481549
[MAGOS] WARN: collision detected on texture ptr: 299B1690
[MAGOS] WARN: tex hash: 4097111396
[MAGOS] WARN: collision detected on texture ptr: 299B1770
[MAGOS] WARN: tex hash: 315185263
[MAGOS] WARN: collision detected on texture ptr: 299B1D90
[MAGOS] WARN: tex hash: 3534146792
[MAGOS] WARN: collision detected on texture ptr: 299B2030
[MAGOS] WARN: tex hash: 4234063710
[MAGOS] Current texturePointerCache size: 60
[MAGOS] Current texturePointerCache size: 85
[MAGOS] Current texturePointerCache size: 91
[MAGOS] Current texturePointerCache size: 91
[MAGOS] Current texturePointerCache size: 91
rapid cargo
#

@shut lichen how tf you get unreal engine 2?

#

this is 2.5 and that would be useful ...

shut lichen
rapid cargo
#

its right on the edge. its 2.5 officially, but since UE3 was coming out soon they ported some features over

#

idk I guess its UE 2.75 😛

shut lichen
#

Lol that might make it trickier then

rapid cargo
#

it had an editor, they never shipped it

image.png
shut lichen
#

I wonder if there are modding tools made that achieve something similar?

rapid cargo
#

not that I know of. bioshock is probably one of the least modded games ever

#

the original one atleast

#

there's some weird stuff floating around to port the game assets to source 2 engine tho

#

Q_Q

#

I love how it says "RTX Remix compatible"

#

wat

shut lichen
#

Moddb's remix compatibility list is not good

fickle moon
#

it needed a massive rework and it never happened 😦

languid totem
#

Awww, they had visions of modded bioshock sad_cat An editor would’ve been so cool back then

rapid cargo
#

@shut lichen you use these at all? or does your editor extract all that?

shut lichen
#

I use umodel for exports

rapid cargo
#

o word

shut lichen
#

That might be better though? Umodel can be a pain to navigate

rapid cargo
#

yeah umodel can be a little crusty. I'll give it a shot. Thinking it would be way easier to en-masse determine all the alpha blended textures from the files and replace them directly instead of taking the runtime penalty to do it

#

although I might be assuming there is a penalty, but it's probably not free

#

looks like shit but its god level software

#

10 bucks

fickle moon
#

lol

#

that's a great ad

rapid cargo
#

heh. supports like 4200 game file formats apparently

#

has some open source code too

fickle moon
#

yeah

#

i've been meaning to try it

rapid cargo
fickle moon
#

so you use it then? if so, would you say it's a worthy addition to some of the tutorials in #1095534398134300682?

rapid cargo
#

I do use it yes. I’d say so. I can’t think of anything else that is as comprehensive. It does cost money, but it’s not an egregious amount

#

I think the free version at least supports reading the file format. So the user could do that in the free version to see if it works before purchasing

rapid cargo
#

@shut lichen screenshot example. Seems pretty powerful 👀

image.png
#

man, you can just do trivial texture pack replacement and everything. just select a group of textures. replace them. easy

mental dome
rapid cargo
rapid cargo
#

need to disable the game's input 😛

shut lichen
#

is that overlay remix related? If you create a bridge.conf you can configure the mouse/key input to not go through to the game. Some games it doesn't out of the box but that setting has helped me personally

rapid cargo
#

huh? nah the overlay is entirely custom (its rendered on the game side). If I turn on the option to disable input to the game I lose the ability to use my menu

#

I need to override it myself, just have been to lazy to

#

mostly because it involves me finding the option to disable its dinput8 stuff, since they dont use window events or any basic windows API I know of to get the mouse position. and I have no idea how DirectInput actually works

#

somewhere in the game I could set a bit and it would all go away, kinda hard without sauce tho atm

rapid cargo
rapid cargo
rapid cargo
#

that feeling when you forget to click save in the runtime and actually click "recompile shaders" instead of "take screenshot" and waste an hour of progress 🙃

rapid cargo
#

working on medical pavilion now. chapter 2. after this chapter I will release a beta so people can start replacing stuff. I haven't replaced a single thing yet, this is all done in-engine. (I am making sure things will work correctly so when people do replace things it works as expected)

fickle moon
#

amazing work

shut lichen
#

IF ONLY WE HAD ReSTIR FG FOR CAUSTICS

rapid cargo
# shut lichen IF ONLY WE HAD ReSTIR FG FOR CAUSTICS

Ikr 😞. I’ll probably end up implementing a custom water shader for this game. It looks so bad right now. And I have no idea how to solve it using anything available in toolkit since remix doesn’t support water materials. I could fake it for now though maybe with glass.

#

Somehow skurty got a water like material here though, which I might have to try for now. It’s the best remix water example I’ve ever seen. Not sure how it works (it uses some valve vmt material)

#general-remix message

fickle moon
#

afaik the game uses an animated map for the texture, and you can just replace those in Remix and assign the water texture tag

#

for a shader based water system yeah you're kinda screwed 😦

shut lichen
#

Remix does have "real" water but it's not even remotely for this purpose. It's for flat planes of water like lakes

rapid cargo
#

Nor toolkit

#

So it’s not real

#

All they have is transparency or translucent

shut lichen
#

well real in that it's an effect that's reuseable under given conditions

#

Xoxor had it in Call of Duty 4

rapid cargo
#

Well whatever it is I’m not following because remix has absolutely zero water material

#

So idk honestly

shut lichen
#

I could be misremembering the details

#

@sour gulch wanna share what your puddles of water in CoD4 were

#

I remember a clip where you dipped the barrel of your gun under the water and it refracted

rapid cargo
# fickle moon for a shader based water system yeah you're kinda screwed 😦

Well it’s kinda half and half here. There is dynamic water volume bodies. But they never interact with the player and are only used on the outside of glass windows. So that can be solved by fog a bit. The few times the player swims in the ocean, it already simulates that well with fog, but I need to create an event system to detect when in the body of water.

For the shader water “streams” at least on lower quality it uses a map of them like you say and scrolls them. I can’t get rid of the alpha on them from remix but if it was done from toolkit it could work a little bit. But that’s just the dynamic splashes of water. Still need a resting style water (pools)

rapid cargo
#

It might have something to do with source engine

shut lichen
#

well that's why I mentioned him getting it in CoD4

#

it's so far removed from source that I doubt it's reliant on a specific thing that's only in Valve games/GMOD

rapid cargo
#

Sorry i replaced cod with portal in my brain

fickle moon
#

remix is designed around source pretty much, so a ton of stuff is reliant on it

#

for example anti culling. it's often very very broken in non source games

rapid cargo
#

True. But if he got it working in COD I’d be interested.

Yeah I wish the anti culling worked better

fickle moon
rapid cargo
#

As long as it’s implemented as a type of material at the end of the day I could probably redo it. But if it’s done dynamically through the engine and it’s generating the new water every frame I’m in trouble 😅

shut lichen
#

oh yeah it 100% was made for use in Source games since that's what Nvidia has remastered, I just believe it can be reused doing some trickery

#

actually @honest badger probably knows too. How to set up water in Remix

fickle moon
#

yeah it definitely can be if you're patching the game anyway

shut lichen
#

he'll roll on by tomorrow most likely

rapid cargo
#

My ultimate solution I had talked with him about before was reimplementing the nvidia perlin noise water material as a slang shader which runs on the path tracing side. Then remix will handle it natively. But I didn’t hear much from him on that. And it’s pretty complicated. Thankfully they wrote more documentation for the shaders than the actual runtime (not trying to be rude, genuinely useful stuff)

rapid cargo
#

Doesn’t half life 2 have water? Maybe I could ask David or something as well what they are doing.

fickle moon
#

ya

sour gulch
rapid cargo
#

Hmm, could work but would be hard. Resting water texture changes every frame from a column list, then it will emplace water drops on it dynamically

#

I’ll give it a shot

#

Well. I guess I can detect all the flat water textures and disable their updates and leave it on the first column, then remove the droplet UV displacement

mental dome
rapid cargo
#

I’m gonna try what Jason did with gmod, and place a large flat piece of glass above the room, project a strong light through it, and hopefully the rays will reach through to the floor

#

If that works possibly a fake caustic pattern can be projected through the glass (or emplaced by a pattern on the glass which shifts)

#

I’d imagine this would be very expensive so it’d be toggleable

rapid cargo
fickle moon
rapid cargo
#

ok

rapid cargo
#

turning it off doesn't really seem to do much visually. I'll stick to the "simpler" sampling method for now

fickle moon
#

yeah it's a very minor difference, enough that i'd be happy with it being off by default tbh

rapid cargo
#

I mean its supposed to be a superior sampling method. confused on how it can have its own name and everything yet visually perform the same as the legacy sampling method

#

seems like a lot of time and effort for ... well I dont know what

#

maybe there's a debug view I can checkout to see the difference better

#

we have nowhere near that level of difference with rtxdi off / vs on

fickle moon
#

yeah it's almost nothing

#

very interesting

rapid cargo
#

its possible im just being a huge jerk and the legacy method is actually some variation of RTXDI (less cycles or something)(. or that DI doesn't really have a big impact in remix as with other games. just playing devils advocate

#

or. or. this is the impact without DLSS

#

which isn't clear from any of the marketting docs

fickle moon
#

either way, it doesn't seem worthwhile 90% of the time

#

also disabling NEE cache can sometimes provide a small performance boost

rapid cargo
#

Yeah I disable that too sometimes. But it’s basically a requirement at this point in this game for emissives

#

With it off the emissive never bounces

#

Which kinda sucks but I’m glad the cache fixes it

fickle moon
#

ya i usually have it on too. in Barnyard since all lighting is emissive, it's 100% necessary lol

#

it was such a huge improvement when it was first added

rapid cargo
#

Yeah I couldn’t imagine it without it. I’d have basically no lighting lol

#

I also turn up it’s training speed to the max

#

Helps smooth out the emissive bounce when moving the camera since it can reflect the change faster, I think

shut lichen
#

what GPU do you have?

#

in my experience just lowering dlss is the easiest bet. After setting bounces to 2 and using ray reconstruction

rapid cargo
#

Only a 2080 😢. Waiting for 5th gen and will immediately buy a 5090

fickle moon
#

so things like this help without making it look like mush

rapid cargo
#

Yeah I always run on perf or balanced. Can’t really do ultra when working on proj since it doesn’t render as faithful as I want and sometimes I gaslight myself

fickle moon
#

ya

#

replacing DLSS with 3.8.x to have preset E would help a lot with visual clarity too

rapid cargo
#

I keep meaning to do that. Tomorrow I will give all the presets a try. I’ve been really missing out on that aspect. I didn’t even know you could do those things

#

The new Ray reconstruct dll is good tho. Fixes sparkling issue I was having before

shut lichen
#

Well you need external tricks to do it. Except if you use the 3.8.10 dll, it'll force preset E which is the best overall and a noticeable improvement for Remix in my experience

rapid cargo
#

Oh ok good to know

shut lichen
#

Oh btw, a really easy software for switching DLSS versions is called DLSS Swapper. Let's you download any dll version straight from the program and it's one click to replace in a library of games on the main page

#

And it works with Remix games. So for me Republic Commando shows up in the list despite that absolutely not being a game that had DLSS lol

rapid cargo
#

Oh neat I’ll def check that out. Thx

#

Right now tho I can average between 30 and sometimes up to 80 inside rooms with a 2080. So I’m guessing that’ll go to something like 100-200 with a 5090. I literally can’t wait.

#

Perf DLSS of course

fickle moon
#

after you release the demo version of this, i can do a comparison on a 4090 for you to have a more accurate guesstimate

#

i get 100+ FPS in a well optimized scene on a 4090 at ultrawide 1440p with DLSS balanced btw. that's with little to no legacy alpha/transparency in the scene

(without frame gen)

rapid cargo
#

Sure that’d be great. I’ve been trying my best to optimize for performance, especially with having a low end card. My mod has extremely minimal overhead even tho it processes every draw call in some way. Probably less than 2% per frame.

Mostly I’ve been trying hard to remove as much alpha as possible from everything since most textures have an unused alpha blend component which sucks huge frame time resources that effectively do nothing. Without alpha blending the performance in some areas is two fold increase. The only other bad perf problem so far is an intermittent vertex explosion that happens during certain draw calls that use a shader remix doesn’t understand for the vertex positions and causes a single frame lockup. But the overhead of that frame is about 10 whole standard frames. (I’ll eventually fix this by hashing out the bad shader during the call)

#

It becomes much less noticeable if you just have a good card

daring iron
shut lichen
#

Oh wait yeah that's gotta come in handy for BioShock in some scenes

honest badger
rapid cargo
#

So it didn’t crash per se. just 1fps

#

When you hit recompile shaders it also opens a new cmd window which switches the current window focus. That causes the renderer to pause in this game, which would then pretty much pause remix. So I’m 99% sure this is not a remix problem (just a jank problem)

honest badger
#

regarding water - I've seen people get nice looking water in several titles. The water textures category just leads to a small bit of code in opaque_surface_material_interaction.slangh that takes a second sample from the normal map with a modified texture xform, which itself is animated based on rtx.opaqueMaterial.layeredWaterNormalMotion

rapid cargo
#

Okay cool. This might sound stupid but bear with me. The water (pooled water) currently only displays as a normal texture. So I need to somehow bind that water normal texture to an actual material underneath, right?

honest badger
#

the game is sending a texture to a draw call, but the (shader?) bound to that call treats it as a normal map?

rapid cargo
#

Yeah 😦

honest badger
#

you should be able to just specify a regular material replacement for that draw call

#

the primary texture gets hashed, regardless of how the game used it

rapid cargo
#

The blue is just a replaced normal texture

#

But this is cool and all, and I can probably optimize this

honest badger
#

what material settings were you using for the replacement material? and did you explicitely override the alpha blend settings? or just uncheck 'use legacy alpha blend' or whatever that's called

#

I think the source engine animates the texture transform of the regular normal map, which is what lets our animated water trick work

rapid cargo
#

I have to go back and get the exact details. But it was just glass basically, not thin walled. And with transmittance. I didn’t disable alpha blending

#

I didn’t try actually

rapid cargo
#

I guess I could … animate it myself

#

Since I can already detect the hash of a texture for every draw call, maybe I can detect it, then transform the normal to like scroll across the surface

#

I finally also added xx hash64 for 32bit so now I have hash parity with remix

honest badger
#

that's actually a feature I've been wanting to implement, and probably reasonable for you to just add to remix yourself - specify a texture transform speed for u and v in the Remix material.

rapid cargo
#

Mmm that sounds straightforward actually. It would be a good exercise as well to familiarize with that level. I could then make a custom category for that

#

Or just re use water

#

Or say water scroll

honest badger
#

no need for a custom category

#

you're just adding a transform to the existing textureTransform based on a material property, so there's no new shader code for it

rapid cargo
#

What do you mean by material property specifically?

#

I understand the rest

honest badger
#

in instanceManager, when it does this:

currentInstance.surface.textureTransform = drawCall.getTransformData().textureTransform;

You just want to get an extra transform from material and multiply that by the frame time so something like

currentInstance.surface.textureTransform = drawCall.getTransformData().textureTransform * (material.getAnimatedTextureTransform() * SceneManager.getGameTimeSinceStartMS() / 1000.f);
#

I don't think SceneManager is available inside of instanceManager, so you may need to pass down the timeSinceStartMS somehow.

rapid cargo
#

Ah okay got it! Just wanted to make sure we were talking about the same thing

honest badger
#

in material_data.h you can just add properties for something like 'vec2 uvScrollSpeed`, and then in RtSurfaceMaterial or MaterialData convert that scroll speed into a transform matrix

rapid cargo
#

Thanks for pointing out the existing timers. Or i probably would have done something stupid with std::chrono 😌

honest badger
#

I think there's already a github issue for scrolling textures. Yet another feature I want to implement but haven't had time for.

gameTimeSinceStartMS is in milliseconds, and is the same thing we use for animating spritesheets. Which doesn't perfectly match the actual game time - we'd need some way to detect pause and slow-mo, which we haven't bothered doing yet.

rapid cargo
#

Well so long as it scales with the frame time it should be good enough for now. Once i get the basics done could probably implement a pause detection and coefficient to adjust the scroll speed

#

I guess an easy way would be to dilate the steps and just scale it by something like (k > n), and only increment k after n cycles

#

@honest badger can I get the frame time from reflex in any simple way? Is there a timer for that?

honest badger
#

the game pausing or going slow mo won't change anything about the frame times Reflex works with

rapid cargo
#

Sorry I haven’t looked at the code yet, I’m at work. I figured it would jitter if the frame time changes.

honest badger
#

It's the same timing that Portal RTX uses to spin the rim of the portal. Do you see that jittering?

#

(For frame times when animating in general, it's usually better to use milliseconds as an int instead of a float, to avoid problems with floating point rounding error over time.)

rapid cargo
#

I’ve never played it. But no

honest badger
#

ah, well I'd recommend just using it as is, and only spending time digging deeper if you actually notice jittering

#

and if you feel like implementing pause detection (texture category for the pause menu maybe)? then I'd recommend just making that pause detection effect the GameTimeSinceStartMS, since then it will be used by everything Remix animates.

rapid cargo
#

Hmm yeah, I guess you would need a pause menu category since you can’t really disambiguate UI textures like that

honest badger
#

Yep. Also some way of detecting bullet time sequences, tho I don't know if Bioshock has any of those

#

That being said - it's not exactly a game breaking issue if the water keeps moving when the game is paused

rapid cargo
rapid cargo
#

pretty happy with that overhead (3.75%)

image.png
valid quest
#

Does bioshock use similar renderer to thief deadly shadows? (thief 3)

rapid cargo
#

I don't know. I've never looked at Thief

#

I doubt it though, this is unreal engine 2.5 and its bastardized with a bunch of custom crap

#

I guess Thief does use UE2, so idk, I'd have to look. Maybe I will in the new year

#

@valid quest I see Thief does a bunch of alpha blending shit which is expected for UE. I had to write some code which is basically a small copy of remix's material/texture hashing framework to handle bypassing alpha blended stuff because remix doesn't support per hash alpha blending adjustments outside of the replacement runtime

#

you can probably fix that game alot by messing with alpha blending and testing, but unless captures work its kinda a pain to capture everything and manually mark things as not alpha blended. And disabling all alpha blend is a no-go since UI elements use it

rapid cargo
valid quest
languid totem
#

WELCOME TO THE CIRCUS OF VALUEEE pepespin

#

Yay watbulbb!! clappypepe

rapid cargo
valid quest
#

did you start off with precision issues and many meshes in the same place? strugglin with this with thief3. also seems like something wrong with the mesh normals, its strange

rapid cargo
#

Sort of. This game incorrectly decides to draw a bunch of geometry untextured, then repeats drawing that same geometry in the same frame with textures. This causes remix to get very confused as it interleaves between untextured and textured

#

So I had to detect all the untextured draw calls and basically fix them up or ignore them entirely for the second pass with the textures

#

Then this game uses an index or stage order to bind certain textures. 0 diffuse / 1 normal / 2 lightmap / 3 specular, etc. you can think of it like a calling convention. I’d disable those texture stages that are problematic for now and let only diffuse through

#

PIX should be able to help with that a lot. Rig up single frame captures and start tearing apart the passes and how’s it texturing, doing blending, etc

#

And yeah I suffer from bad precision issues on the object transforms. This is excacerbated by ray reconstruction and causes significant transform jitter when enabled for whatever reason. As soon as RR is disabled VP jitter reduces significantly. Right now I take the lower half of the WVP floats and round their precision to the 4th decimal

#

I’m guessing that since i sit in front of the bridge calls I can visualize the jitter in realtime, it doesn’t happen without the bridge so there are floating issues around there that don’t have much to do with the game. It’s a remix thing. If I visualize the object WVP with and without remix there is no jitter

#

You might want to enable d3d9.invariantPosition in dxvk.conf. Or test it with vanilla dxvk

#

”Declares vertex positions as invariant in order to solve
potential Z-fighting issues at a small performance cost.”

quiet talon
#

Damnnn i came in here to look at cool lights not readddd

(This is a joke please don't kill me)

valid quest
rapid cargo
#

so weird. getting driver crash when reading vertex constant from shader ??

assert(SUCCEEDED(m_pIDirect3DDevice9->GetVertexShaderConstantF(binding.StartRegister, &lightVector[0][0],  binding.Vec4fCount)));

just randomly fails at times, deconstructs and then m_pIDirect3DDevice9 turns into nullptr ??

#

threads be damned

#

just randomly started happening too, haven't touched this part of the code in a week

#

what the fuck:

image.png
#

somehow the whole D3D9Device object goes out of scope or the thread gets destroyed?

#

maybe I should just remove the deleter, idk

rapid cargo
#

Oh … indeed the thread does die …. boldyikes

#

I think I've had enough computer for today. re-installing driver and rebooting PC fixed it

rapid cargo
rapid cargo
#

office

office_1.png
rapid cargo
#

@honest badger if you have any thoughts about this, would be appreciated. So on the tangent of world transform shader stuff. I spent some time looking at the scene manager again, and came across convertLight and what it calls (SceneManager::createEffectLight).
This seems like a logical place right? We have some instance, which has a material hash or mesh hash we know about, we pass this hash and the instance to createEffectLight to attempt to bind the light to the instance geometry. In a naive sense you'd expect to be able to do this if the scene manager has a copy of the game's scene, so it should know the positions of the instances based on the geometry data. This fails though in this game when it looks at the buffer data here, for every single instance in the game: https://github.com/NVIDIAGameWorks/dxvk-remix/blob/368525a7eedea156203502583f8860a3d05d955e/src/dxvk/rtx_render/rtx_scene_manager.cpp#L627

#

This confuses me, because I don't understand why it can't access this data here ...

#

I guess there is no position buffer 🤷‍♂️

honest badger
#

Vertex buffers can exist on the HOST (cpu) and DEVICE (gpu). It's slower for them to exist on both, so generally they're only going to exist on the gpu (and thus be inaccessible from the cpu).

You can change the flags in the place where the buffer is created to make that data available on the cpu and gpu, but that's generally only good for debugging.

We do, however, calculate a bounding box for that vertex data, which should be available around there...

rapid cargo
#

ohhhh, I see

honest badger
#

input.getGeometryData().boundingBox.getTransformedCentroid(transform) where transform is referenceCamera->getViewToWorld(false) * drawCall.getTransformData().objectToView

#

that wil get you the point that is the center of the bounding box of the mesh, transformed into world space

#

the code I copied is from InstanceManager::processSceneObject and InstanceManager::findSimilarInstance

rapid cargo
#

oh okay. So if I don't want to make the buffer host visible, I can basically bypass the point cloud centroid calculation and just take the mesh bounding box?

honest badger
#

yep. we calculate the bounding box at the same time as we calculate the hash, but that all happens on a separate thread.

rapid cargo
#

do you think that createEffectLight could be optimized generally to do that instead? Or is there a good reason do to the centroid calculation that way?

#

that way as in how its currently done

honest badger
#

I suspect createEffectLight predates that, and was just never updated after we had it

rapid cargo
#

rgr makes sense

#

I shall try this right now xorxor

rapid cargo
honest badger
#

I think it's host visible when it comes from the game, but we have to copy buffers a few time, and we need to release the CPU copy of that buffer back to the game before sceneManager actually processes that draw call

rapid cargo
#

right makes sense, so host visible while copy, then release and copy to GPU

honest badger
#

(basically, the game sends in a d3d9 call with cpu visible buffers, we process that, then return so the game thread can continue. But we want to keep that time minimal, so we basically just copy stuff off and then run sceneManager in a separate thread)

#

I haven't actually looked at that stuff in a while, but it's entirely possible we have logic to keep a cpu copy of the data around for some draw calls and not others

#

either way, the bounding box should be available for all draw calls

rapid cargo
#

cool. in either case I can directly control the buffer visibility through my hooks. so either case I should be able to debug this kind of stuff now that I understand better

rapid cargo
#

@honest badger it appears to be ... working. but not visibly ... in the debugger the transformed positions look good happycat. but remix is showing no lights rendered

#

is there something Im missing about:
m_lightManager.addLight(rtLight, input, RtLightAntiCullingType::MeshReplacement);

#

hmm maybe I need to change that

honest badger
#

have you tried turning on the light debugging view?

#

in the rendering tab under lighting, there's a way to make lights show up, show their hashes, and show all their properties on mouse hover

rapid cargo
#

I did yes, it just shows 0 sphere lights 😟

#

but its calling addLight Confused

honest badger
#

and the rtLight you're adding is a sphereLight?

rapid cargo
#

yep, looks like it:

    RtLight rtLight(RtSphereLight(lightPosition, lightRadiance, lightRadius, shaping));
    rtLight.isDynamic = true;

    m_lightManager.addLight(rtLight, input, RtLightAntiCullingType::MeshReplacement);
honest badger
#

Well, if you're set up for breakpoints, you should just step through addLight and make sure it's not early outing on some condition

#

there are a few places it can

rapid cargo
#

yep, all setup

honest badger
#

then yeah, just drop a breakpoint and step through it, see what happens to your sphere light

rapid cargo
#

ahhhh, its failing literally at the top ??

# 
    const Vector3 originalRadiance = rtLight.getRadiance();
    if (originalRadiance.x < 0 || originalRadiance.y < 0 || originalRadiance.z < 0
        || (originalRadiance.x <= 0 && originalRadiance.y <= 0 && originalRadiance.z <= 0))
      return;
honest badger
#

so, the brightness is 0

rapid cargo
#

im just using the code from createEffectLight so it might be out of date?

#

or do I need to enable the plasmaball. hmmm

#

lemme see

honest badger
#

it's grabbing the diffuse color from your draw call. if that color is black, all of those values will be 0

#

or if your radianceFactor is 0... you can jump up a couple of levels in your call stack and check what those values are

rapid cargo
#

thats a little weird, because I bypassed the code and set it to call createEffectLight for every instance in the scene

#

so all the colors are black?

honest badger
#

It's just getting this:

      const D3DCOLORVALUE originalColor = input.getMaterialData().getLegacyMaterial().Diffuse;

It's possible that defaults to black and the game simply doesn't use it, since it's shader based

rapid cargo
#

ahh okay. ill check whats goin on

honest badger
#

easy hack to test, just hard code the radiance to lightRadiance = Vector3(1.f, 0.f, 0.f) * radianceFactor;

#

and all of your lights should show up as green

rapid cargo
#

yep thats why, the material is just black. fixing the code to not call it on every instance so as to not blind myself and test further

#

IT WORKS!

#

this game has a problem where I can't actually see the hashes for some reason in the debug view

#

but it does work

#

well, it sort of works. but the positions never update for my selected mesh. doing this for worldPos:

    const auto transform = getCamera().getViewToWorld(/* freecam = */ false) * input.getTransformData().objectToView;
    const Vector3 geometryBoundingBoxWorldCentroid = geometryData.boundingBox.getTransformedCentroid(transform);
    const Vector3 worldPos { geometryBoundingBoxWorldCentroid };
#

but atleast its able to get some distinct position from the instance hash ... some sort of progress

#

@honest badger is there a difference between referenceCamera and getCamera()?

#

okay im going to record a clip to show this better

#

the vehicle is the instance target. the position is about ~ (100, 60, 45) constantly, but under the debug camera it stays where it should ... am I using the wrong camera transform ... how's that possible?

#

it'll always show in front since the camera from the game always reports 0,0,0 if we never use SetTransform, as expected

honest badger
#

there's a whole case for trying to get the objectToWorld matrix when it's not set normally

#

the code I copy/pasted was from there

#

you may need the entire set of logic in that area to get a useable objectToWorld

rapid cargo
#

okay, will do, thanks

rapid cargo
#

could this have something to do with users reporting that dxvk works well with this game if they use "invariantPosition"?

honest badger
#

have you seen what the light visualization is supposed to look like when it's actually working?

honest badger
honest badger
rapid cargo
#

I thought maybe it might be because the position index is randomly changing or something

#

its the only thing I can think of, but yeah looks like random data

honest badger
#

are the bounding box and transform matrices stable when the camera is still?

rapid cargo
#

to make it visible I do a:

   DxvkBufferSlice allocVertexCaptureBuffer(DxvkDevice* pDevice, const VkDeviceSize size) {
     DxvkBufferCreateInfo info;
     info.usage = VK_BUFFER_USAGE_STORAGE_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_SRC_BIT | VK_BUFFER_USAGE_VERTEX_BUFFER_BIT | VK_BUFFER_USAGE_INDEX_BUFFER_BIT;
-    info.access = VK_ACCESS_TRANSFER_READ_BIT;
+    info.access = VK_ACCESS_TRANSFER_READ_BIT | VK_ACCESS_HOST_READ_BIT;
     info.stages = VK_PIPELINE_STAGE_VERTEX_SHADER_BIT | VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT | VK_PIPELINE_STAGE_TRANSFER_BIT;
     info.size = size;
-    return DxvkBufferSlice(pDevice->createBuffer(info, VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT, DxvkMemoryStats::Category::AppBuffer));
+    return DxvkBufferSlice(pDevice->createBuffer(info, VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT | VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT, DxvkMemoryStats::Category::AppBuffer));
   }

seems correct?

honest badger
#

and how do they change when you turn the camera or move around?

#

I believe that's right (for making the buffer visible)

#

Tho do keep in mind that the vertex data may be interleaved - reading it correctly is more than just starting at the positionIndex

rapid cargo
honest badger
rapid cargo
#

I don't think so because it always resolves to the same position using the bounding box way no matter which position the camera is

honest badger
#

oh, are you looking at the actual bounding box values, or the centroid returned by getTransformedCentroid?

rapid cargo
#

by resolved value I mean:

    const auto transform = getCamera().getViewToWorld(false) * input.getTransformData().objectToView;
    const Vector3 geometryBoundingBoxWorldCentroid = geometryData.boundingBox.getTransformedCentroid(transform);
    const Vector3 worldPos { geometryBoundingBoxWorldCentroid };

so worldPos is always the same. I need to double check just the bounding box.

#

So yes, the centroid

honest badger
#

yeah, the centroid is basically the bounding box, transformed by that transform matrix. So if the centroid is constant as the camera moves, either those two are both constant, or somehow they're cancelling eachother out

rapid cargo
#

ill check the bounding box

#

I guess this isValid check does happen in getTransformedCentroid, not sure if relevant:

  Vector3 getTransformedCentroid(const Matrix4& transform) const {
    if (isValid()) {
      return (transform * Vector4(getCentroid(), 1.0f)).xyz();
    } else {
      return transform[3].xyz();
    }
  }
#

hmm, I guess that just checks it for crazy bounds

rapid cargo
#

just confirmed that the bounding box is always the same no matter what the camera angle:

minPos = {data=0x0000006c63dfdbd0 {-23.7952003, -0.173500001, -112.141403} x=-23.7952003 y=-0.173500001 ...}
maxPos = {data=0x0000006c63dfdbdc {45.2941017, 237.994293, 121.907204} x=45.2941017 y=237.994293 ...}

but unfortunatately the camera transform is never updating, so the lightPosition is always the same:
0 degrees dead on looking and 45 degrees to the left:

lightPosition = {data=0x0000006c63dfdbc0 {10.7494507, 118.910400, 4.88290024} x=10.7494507 y=118.910400 ...}
lightPosition = {data=0x0000006c63dfdbc0 {10.7494507, 118.910400, 4.88290024} x=10.7494507 y=118.910400 ...}
lightPosition = {data=0x0000006c63dfdbc0 {10.7494507, 118.910400, 4.88290024} x=10.7494507 y=118.910400 ...}
honest badger
#

I thought the bounding box was being calculated after the vertex shader is run... if it's actually calculated beforehand, then that might explain some other bugs that have come up

rapid cargo
rapid cargo
#

@honest badger I’m really curious to dig into some of the position interleaving stuff here as well. I whipped up a quick script that double checks that dcl_position is always at register v0 (or very few times o9?). Hopefully if I can figure out its interleaving. maybe I could go back to the old but gold way, at least to debug. But yeah, the stride is definitely not 4 here … hmmm

#

Oddly there are two vertex shaders that call for position decl twice …

#

Technically the fourth row in a WVP is the position, but I’d need another transform to scale it back

honest badger
rapid cargo
#

Ahhh okay. 👍. I’ll take a look at that

#

Thanks

rapid cargo
honest badger
#

check out src\d3d9\d3d9_rtx_geometry.cpp, particularly computeAxisAlignedBoundingBox.

You could probably add code there to also compute the centroid for the RasterGeometry, and store that with the bounding box

#

unfortunately, that still may be the pre-vertex shader vertices....

#

RasterGeometry is the data from the original draw call. RaytraceGeometry is the interleaved data

rapid cargo
#

oh I see, I guess im not clear on that aspect yet. so you're saying certain points in the pipeline the transforms haven't been applied to the positions so they (quite obviously) aren't changing?

#

like through the shader

#

oh, is that why geoData.futureBoundingBox is a future 😅 ?

honest badger
#

yeah.

I don't know this flow very well, but you can start from d3d9_device.cpp's DrawPrimitive function and follow it from there. PrepareDrawGeometryForRT is what schedules the geometry work to be done, then D3D9Rtx::CommitGeometryToRT schedules the CS thread to actually process the results. That all blocks the the game's render thread.

in RtxContext::commitGeometryToRT we wait for the futures to be ready, then actually handle the output.

The vertex shader handling happens in the PrepareDrawGeometryForRT call, but I don't actually know if the AABB calculation waits for the vertex shader capture to be done. the vertex shader capture is in D3D9Rtx::prepareVertexCapture

rapid cargo
#

🤔

    // NOTE: May be better to move reverse transformation to end of frame, because this won't work if there hasnt been a FF draw this frame to scrape the matrix from...
    const Matrix4& ObjectToProjection = m_activeDrawCallState.transformData.viewToProjection * m_activeDrawCallState.transformData.worldToView * m_activeDrawCallState.transformData.objectToWorld;
hexed drum
#

is there any mods available for Bioshock right now or has nobody gotten that far yet

rapid cargo
hexed drum
#

alright

rapid cargo
#

@honest badger I think I understand now ... I need to get the post-transformed state from programmablePipeline (prevCB.programmablePipeline) ? which will have some of the required post-shader transforms like viewToProj, worldToView, etc

#

i.e D3D9RtxVertexCaptureData modified = prevCB.programmablePipeline;

honest badger
rapid cargo
#

hmm okay, so I should check teh call state once all the pending futures are finalized

honest badger
#

yep... though keep in mind that means the data is going from cpu to gpu, running the vertex shader, then has to go back to the cpu to let you run your code

rapid cargo
#

hmm, but this will possibly be a needed expense for now, I can probably limit it by the lightConverter hash or something to that effect for the time being.

#

Eventually I would imagine you want the AABB to work on the post transformed stuff too?

honest badger
#

yeah, maybe only doing it for select meshes. and yeah, it'd be better to have the AABB be post-transform, but making every draw call wait on a round trip to the GPU would be really slow

rapid cargo
#

for sure. maybe I'll tinker with some ideas

#

@honest badger oh well look at this:

  bool DrawCallState::finalizePendingFutures(const RtCamera* pLastCamera) {
    ScopedCpuProfileZone();
    // Geometry hashes are vital, and cannot be disabled, so its important we get valid data (hence the return type)
    const bool valid = finalizeGeometryHashes();
    if (valid) {
      // Bounding boxes (if enabled) will be finalized here, default is FLT_MAX bounds
      finalizeGeometryBoundingBox();

we are finalizing the bounding box and setting it to that post finalize:

geometryData.boundingBox = geometryData.futureBoundingBox.get();
#

so I will double check that createEffectLight is moved forward to ensure the finalization is run first before referencing the boundingbox

honest badger
#

we're definitely hashing the pre-shader vertices though.

rapid cargo
#

mmm, you're right. I need to spend more time looking at the order of operations here. Because as I see it DrawPrimitive->CommitGeometryToRT->commitGeometryToRT->submitDrawState->processDrawCallState->createEffectLight
and finalizePendingFutures happens during commitGeometryToRT

#

maybe the object picking might be worth looking at too? since it should have some info by that point?

honest badger
#

object picking is done by drawing a unique color to a texture depending on the primary object the ray hits, then checking the pixel the mouse is over

rapid cargo
#

think I found a way to get the position from a BlasEntry in the accelmanager after processing the instance. if this sounds stupid let me know 😛

rapid cargo
#

ahhh I understand now, exec barriers are passed into the accelmanager to track the original buffer resources to queue on when the device is finished the submission

valid quest
#

i'd love to see your tooling and workflow sometime watbulb 😄

rapid cargo
rapid cargo
#

aghhhh, I can't access the modified geometry position buffer even after making it host accessible 😱

    for (uint32_t surfaceIndex = 0; surfaceIndex < m_reorderedSurfaces.size(); surfaceIndex++)
    {
      
      RtInstance& surface = *m_reorderedSurfaces[surfaceIndex];
      const AccelManager::SurfaceInfo &info = m_lastSurfaceInfoList[surface.surface.surfaceMaterialIndex];

      if (surface.buildGeometries.size() == 0) {
        continue;
      }
      if (!lookupHash(RtxOptions::lightConverter(), surface.getMaterialDataHash())) {
        continue;
      }
      AxisAlignedBoundingBox AABB = computeRaytraceAxisAlignedBoundingBox(surface.getBlas()->modifiedGeometryData);
#

tbh I barely know what im doing, but learning about how the accel manager works is cool

rapid cargo
#

I need to do more thinking to figure out the weird interleaving since its replacing the geometry data before I expect it to

#

the viewmodel stuff seems to use a compute shader to get the positions or something to that effect from the modified blas geometry data

honest badger
#

well... painful to look at ,but I guess that's an improvement

rapid cargo
#

haha yeah

honest badger
#

you're diving into code I haven't looked at in a long time, and never really understood well. but I'm happy to see you're making progress

rapid cargo
#

thanks, I don't understand it very well either 😅

#

lots of dxvk and vulkan black magic happening here

honest badger
#

yep

rapid cargo
#

maybe I should try this in another title to make sure its not the game doing something strange

real stone
#

My man hit you with the. "I'm happy for u bro"

rapid cargo
#

I think I found the reason, I wasn't expecting the scene manager to dispatch the accelmanager to call buildBlas multiple times in one frame. so I end up reading the wrong position eventually. Only one of these is correct between frames:

End Frame
124.579 127.126 127.126 
112.436 126.5 -280.199 
127.5 127.5 127.5 
-734.166 -5281.66 1460.16 
-734.378 -5901.72 1429.91 
74.0035 -4014.58 1445.23 
-648.582 1132.85 -573.642 
63.5 63.5 127.5 
End Frame
#

probably some threading stuff I dont understand yet

honest badger
#

AFAIK mergeInstancesIntoBlas and buidBlases should only be called once per frame, though I suppose it depends on where you're printing End Frame from

rapid cargo
#

I stopped trying to create the light from mergeInstancesIntoBlas after the execbarrier and instead am using the SceneManager's onSceneObjectUpdated hook, and SceneManager EndFrame to track when (I think) the frame is over

honest badger
#

SceneManager::EndFrame should be the right place for that. I'd recommend using SceneManager::processDrawCallState instead of onSceneObjectUpdated - processDrawCallState always gets called, but onSceneObjectUpdated is conditional.

rapid cargo
#

makes sense. but for performance reasons, what I did is cached a copy of all the RtLights bound to all the seen lightConverter hashes in a array, then if the scene object updates its position I update the light bound to the surface object instance, otherwise it just uses the cached light. Do you think that makes sense to only update if the geometry positions change?

#

or am I wrong in assuming that the positions might not be a conditional update for the scene object?

#

well, it might actually be bad, you're right, since the update only occurs if it was cached

# 
    if (m_drawCallCache.get(drawCallState, &pBlas) == DrawCallCache::CacheState::kExisted) {
      result = onSceneObjectUpdated(ctx, drawCallState, pBlas);
#

I dont actually know what that means yet

#

I should just use processDrawCallState and worry about that later. ideally I only want to update the light if the position changes, but I think the lightmanager has a low overhead for redundant light calls anyways because it hashes them and checks similiarity

#

or I just lookup the cached light and checks its position, if its the same bail out early

rapid cargo
honest badger
#

Just Mark it as a dynamic light and send it new every frame

rapid cargo
#

yeah im doing that right now

#

ill post a more detailed explanation of my exact process a little later

honest badger
#

I'm gonna be phone only and super busy for the next few days. Are you basically just attaching a light to a mesh based on the mesh hash? I assume doing it with replacements doesn't work, but could you just set up an option to handle lights attached to messages differently?

#

Look at drawReplacements in the scene manager

rapid cargo
#

I've tried a few times to go down the drawReplacements path, but I've never been able to make it work. I know its possible through there to basically draw a light as a type of replacement for a mesh, but its always used the previous method that wasn't working where the light would just move with the camera since the camera is 0,0,0 every frame, based on the the fact the matricies or transforms aren't being scraped at that point I don't think, since there are no FF calls

#

and no problem, always appreciate you taking the time away to help out

#

but yes to answer your question, im trying to do exactly that, since its going to be the easiest way going forward to add real lights into shader games

#

yeah, im not sure in drawReplacements the transforms for the replacement have been updated to the modified one:

    for (auto&& replacement : *pReplacements) {
      if (replacement.type == AssetReplacement::eLight) {
        if (rootInstanceId == UINT64_MAX) {
          // TODO(TREX-1141) if we refactor instancing to depend on the pre-replacement drawcall instead
          // of the fully processed draw call, we can remove this requirement.
          Logger::err(str::format(
              "Light prims anchored to a mesh replacement must also include actual meshes.  mesh hash: ",
              std::hex, input->getHash(RtxOptions::Get()->GeometryHashGenerationRule)
          ));
          break;
        }
        if (replacement.lightData.has_value()) {
          RtLight localLight = replacement.lightData->toRtLight();
          localLight.setRootInstanceId(rootInstanceId);
          localLight.applyTransform(input->getTransformData().objectToWorld);
          m_lightManager.addLight(localLight, *input, RtLightAntiCullingType::MeshReplacement);
        }
      }
    }

but I can double check. if not I can modify this function maybe to grab the new positions

#

unless somehow input->getTransformData from the transformbuffers is being made re-visible once processed. anyways. gtg

rapid cargo
#

@honest badger just braindumping my approach here. no obligation to respond obvisouly since y'all are away.

So first, basically I re-wrote a copy of SceneManager::createEffectLight which tries to recalculate the bounding box for the blas geometry for the instance by material data hash (pBlas->input.getGeometryData()).
But this is silly because that is probably the pre-transformed data, and sometimes I think I just get lucky. Those buffers are copied to the GPU, once I read them back it's got undefined data as per the code comment:

// Stores a snapshot of the geometry state for a draw call.
// WARNING: Usage is undefined after the drawcall this was 
//          generated from has finished executing on the GPU

Possibly sometimes it's the actual post transformed data. That's the only thing that would make sense as to why it is the correct position sometimes, because those buffers are definietely not the BLAS modified geometry data, which for example the GameExporter needs, and I need. It's the only geometry data I am using currently.

Anyways, to call createEffectLight / createTestLight, I just override where it was being called previously in SceneManager::processDrawCallState after the instance manager processes the scene object:

...
    RtInstance* instance = m_instanceManager.processSceneObject(m_cameraManager, m_rayPortalManager, *pBlas, drawCallState, renderMaterialData, surfaceMaterial);

    // Check if a light should be created for this Material
    if (instance && RtxOptions::Get()->shouldConvertToLight(drawCallState.getMaterialData().getHash())) {
      createTestLight(instance, pBlas);
    }
...

What I think I need to do now is basically copy the pBlas->modifiedGeometry data off the GPU, instead of using the original drawCallState geometry info, which, if im reading the code right, is not going to ever have the post-transformed positionBuffer, unless by some fluke of how the buffer semantics work (undefined).
So during computeRaytraceAxisAlignedBoundingBox (see createTestLight.c comments) instead, I can basically copy that buffer off using some approach like this:

      const size_t positionStride = inputPositionBuffer.stride() / positionSubElementSize;
      const DxvkBufferSlice positionBuffer(posBuf, 0, posBuf->info().size);

      // Ensure no reads are out of bounds, this should be the modified gemoetry buffer
      assert(((size_t) (numVertices - 1) * (size_t)inputPositionBuffer.stride() + sizeof(pxr::GfVec3f)) <=
            (positionBuffer.length() - inputPositionBuffer.offsetFromSlice()));

      // Get copied-to-CPU GPU buffer
      const float* pVkPosBuf = (float*) positionBuffer.mapPtr((size_t)inputPositionBuffer.offsetFromSlice());
      assert(pVkPosBuf);

      // Copy GPU buffer to local VtArray
      std::vector<Vector3> positions;
      positions.reserve(numVertices);


     // XXX: Here we would do some variation of
     ctx->copyBuffer(bufferDest, VkDeviceSize { 0 }, buffer.buffer(), buffer.offset(), desc.size);

then we'll have the modified post-transformed positionBuffer copied back, compute the AABB, set the transform, and hopefully its correct 🤞

#

another method would be to write a compute shader which grabs them off the GPU side async, but thats probably gonna be no bueno for lights

rapid cargo
rapid cargo
#

woohooo, it works! there's an issue I need to solve where im not waiting for the modified geometry to finish, but the positions are correct!

#

🥹 finally lights in shader games

#

@serene trellis finally, lights in ratmix shader games. just use a execution barrier to determine when the GPU is done transforming the positions, then copy them back clueless

serene trellis
#

Copy back

rapid cargo
#

yeah super great for perf. luckily I only need to do it for one draw call out of 800 on average

#

that might scale to like sub 100, but no more than 100

hexed drum
#

whas going on in here

rapid cargo
#

making lights work in games that never send a fixed function view transform

#

i.e shader games

hexed drum
#

so funnn and obviously not time consuming

#

... right?

rapid cargo
#

depends what you constitute as fun, probably not, but having shader games have properly working lighting transforms for meshes makes remix better for everyone

#

so more fun in the future

hexed drum
#

i hope it goes well then

rapid cargo
#

okay, it works now. unnoticeable overhead with a few lights. @honest badger I think I should be able to integrate this into drawReplacements, and check the drawCallState for vertexshader usage. if yes, it will take a different path that computes the AABB for the RaytraceGeometry and uses that position instead. Hopefully that should be okay? I can profile it if you want to see what the impact would be.

📎 rtx_scene_manager.cpp.diff
rapid cargo
languid totem
#

WATBULB YOU’RE A GENIUS!! clappypepe BLANKIES BLANKIES

rapid cargo
#

finally we can have this in TRL too now. well every game can have it. mark is going to yell at me because its expensive. but I mean I'm running the game at 2k there with 1 / 4 bounces and volumetrics on a 2070 and its getting 30 fps

hexed drum
#

what happened

#

i want to know

rapid cargo
#

well basically games that use shaders can now have light and mesh replacements

fickle moon
#

magic 😛

hexed drum
rapid cargo
hexed drum
#

aight

rapid cargo
#

games that use shaders use pre-combined transforms (matricies) by the time they hit the rendering API. You could reverse engineer the game and get the original pre-multiplied transforms, but that can be even more time consuming and difficult. Instead we basically let the GPU process the positionBuffer from the vertexBuffer and transform the geometry from the shader. Once the GPU is finished processing the vertex data, we read its position information back, and use that to position lights in the world

#

for example a World * View * Projection matrix cannot be decomposed quickly without atleast the projection matrix, and even then it can be difficult to get the actual world position back

#

so we let the GPU compute the world position and then read it back to where the renderer expects

hexed drum
#

ion understand any of that but like yeah cool dude amazing as long as it gets it a tiny bit closer to bioshock rtx remix

rapid cargo
#

it'll be ready when its ready 🤷‍♂️

hexed drum
#

yuuup

rapid cargo
#

hmm technically I only need to compute the AABB once if its a static mesh. then I can just transform the AABB itself by the new instance transform. the static AABB will only have 8 verticies versus the whole mesh verticies set:

A: previous AABB
B: current  AABB

// Split the transform into a translation vector (T) and a 3x3 rotation (M).
B = zero-volume AABB at T
for each element (i,j) of M:
   a = M[i][j] * A.min[j]
   b = M[i][j] * A.max[j]
   B.min[i] += a < b ? a : b
   B.max[i] += a < b ? b : a
return B
rapid cargo
languid totem
#

it's so beautiful FeelsStrongMan

rapid cargo
#

have to work on some flickering problem. but I'll pick up on this after the holidays

quiet talon
#

Enjoy your holiday om gang watlub

rapid cargo
#

you too 🙂

languid totem
#

Yeah enjoy the holidays! 🎅

rapid cargo
honest badger
# rapid cargo quite alot better now

Well, that certainly looks like quite a bit of progress.

If you can send off the request to compute the post-shader AABB earlier (possibly even attaching it to the actual vertex shader call), you'd probably reduce the latency this might be causing.

rapid cargo
#

Learning about the acceleration manager inspired me to actually pick up a book and understand the basics of path tracing. I’ve been having a lot of fun following Peter Shirley’s book

4DBD1C73-06A5-47FE-B191-7651CDD16C70.png
#

Well book(s). I’m on the second one now

serene trellis
#

Rat racing in a weekend

rich dawn
#

Rat racing in the next week

#

The second book have BVH structures for easier path tracing

rapid cargo
#

Yes I know 😌

rich dawn
#

I got around the hittable_list.h part but still need to learn more

rapid cargo
#

I can share you my code for the first book if you want

#

Tbh the first book teaches a ton of bad practices that make me cringe. The book is inconsistent with the code and the code is inconsistent with the book.

  • Poor naming of classes
  • Forward declarations are a no-no if it’s not needed.
  • there’s multiple errors in the book where he uses the pre increment operation on j (++j) instead of post
  • the rtweekend is a horrible single header design.
  • he includes headers at the bottom of source files
#

The material is solid but boy is the code bad

#

Which is a shame because you are supposed to build off it for all the other books

#

I also don’t really buy his “matter of taste arguments”. Either do it right or do it wrong

#

Some of it has nothing to do with taste

#

There’s other issues on the repo that point this out

rich dawn
#

That's a lot of issues, never thought about them because I'm still learning C++

#

There's a lot of header files

#

In his tutorial book

#

But I'm just here for the concepts behind Path Tracing

rapid cargo
#

I like to nitpick a lot but I also review c++ code for a living so I’m a little biased. I went with even more headers personally with a cleaner structure

rich dawn
#

oh nice

rapid cargo
#

But yeah what it teaches is super solid. I’d definitely read a couple more books on software construction to get a better insight into some of the more correct design patterns though

#

I enjoyed code complete a lot when I was in school. But that more focuses on clean code and construction over specifics

rich dawn
#

Are there some books you can recommend

#

Like for C++

#

Right now I feel like you can get a lot of help from online resources and AI assistants but I'd rather rely on myself

rapid cargo
#

Sure. Code complete is one for sure. It’s a huge book, so don’t read it all. In fact I don’t think there are any decent books either than maybe some bjarne books that teach that actual OOP aspect well, it mostly comes down to construction patterns.

Most of the difficulty people have with c++ isn’t really understanding the language itself, especially if you have a fundamentally decent grasp on OOP, but understanding all 4 “meta” languages or paradigms at play when learning C++.

When you are learning C++ you are effectively learning 4 languages at the same time.

  1. The core OOP language. And it’s important to stick to this object paradigm and not pretend that C++ is C and vice versa. They are distinctly different languages, so try not to write C code in C++.

  2. the STL: the STL is a whole language amongst itself, and for that reason an entire class or book should be dedicated to its understanding and inner workings, it’s not the language, but instead uses the language.

  3. You’re learning the language of the computer and compiler and how the choices you make boil down to compiled instructions. People say this doesn’t matter and you can’t outsmart the compiler. Those people are dead wrong. That’s a language amongst itself. Especially when dealing with portability.

The fourth is probably meta programming, but focus on this last

#

I’m not a big fan of recommending books because books go out of date, I’m more a fan of recommending learning strategies

#

I’ve been writing C++ for probably 20 years now and I still learn shit all the time

#

Mythical man month is also a good book. Doesn’t teach programming but instead talks about discipline and practice. Which I find more important. The biggest language nerds are sometimes the worst programmers I’ve even seen because they languish in the limelight of looking at shiny perfect code rather than learning the fundamentals of constructing good code. Focus on that. Its philosophical

serene trellis
#

20 years is crazy

#

Enjoyed your boost libs back in the day?

#

Of pre cpeepee 11

rapid cargo
#

I was one of those guys that still bangs on not using boost because I’m tired of swatting a mosquito with a double decker bus

#

Shit is whack if you ask me

serene trellis
#

I mean

rapid cargo
#

Yeah it has good stuff but not for learning imo

serene trellis
#

Yeah, that's the popular opinion

#

Which sounds about right from what i've seen

rapid cargo
#

Also yeah C++ 11 was the last good C++

#

I subscribe to this now pretty much for a long time

serene trellis
#

I mean constexpr is pretty good

rapid cargo
#

This is true. I do use that a lot now

#

I also really like generics

#

And concepts

#

But not templates

serene trellis
#

Also iirc they fixed some thingy in 17 with maybe move semantics i don't remember

#

You really like oop, huh?

rich dawn
rapid cargo
#

Nah not really. I only really do C++ at work. I honestly write most of my personal projects in Python because it’s simple and I literally don’t give a fuck how the performance is, I just want to be able to write it fast and now

serene trellis
#

pythong

#

🐍

rapid cargo
#

so good. Maybe before I die someone with a big brain will finally figure out how to make the GIL multithreaded

#

Like holy shit

serene trellis
#

I hate the cringe syntax with no brakets for scope ngl

rapid cargo
#

That’s fair

#

Pythong with brackets coming in Python 4 ™️

#

I’m kinda a language polyglot tho. I know like 10 or so of them I guess

#

But I only really use like 4 or 5

#

Still write C a lot. Still do assembly at work. I do SystemVerilog a lot at work too. Bash for everything that needs to be at my fingertips.

#

But fuck them web langs

serene trellis
#

Yes

rapid cargo
#

I’m also a terribly mean person to rusties but I can’t help it

#

Every bone in my body says I don’t need this

serene trellis
#

Omg

#

bestie

rapid cargo
#

And I don’t need it

#

Like there’s definitely times at work we’ve written things that take a lot of unstructured user input and write it in rust. But it’s also per application and highly specific.

Some dude at work wrote a documentation generator in rust and I’m just like what the fuck are you doing dude

#

Like you try to make some Arc thread unmaintainable mutex shit to generate a word doc?

#

Why?

#

Use the language for what it’s for. I’m not translating a decade of software to your paradigm because you have fallacies of how allocators and modern compilers work

#

Also 90% of developers have never looked a static analysis tool, a fuzzer or valgrind in the eye for more than a glancing second

#

So it makes sense they reach for the thing that saves them from reality

serene trellis
#

Drugs?

rapid cargo
#

Possibly

#

On both sides 😌. One to cope and one to seethe with

rapid cargo
#

@rich dawn if you get deeper into the materials stuff, I find its better to create a MatProp struct and pass that around versus the lengthy and kinda hard to balance long lines of shared_ptr materials bound to each sphere. I ended up doing it like this to take advantage of designated initializers, which are so much clearer:

  // Shapes and their respective materials
  using MetalSphere      = Sphere<MetalMaterial>;
  using LambertianSphere = Sphere<LambertianMaterial>;
  using DielectricSphere = Sphere<DielectricMaterial>;

  // World objects
  auto ground_sphere = LambertianSphere(
    Point3f(0.0, -100.5, -1), 100.0,
    MatProp<> {
      .albedo = Color(0.5, 0.5, 0.5)
    }
  );

  auto center_sphere = LambertianSphere(
    Point3f(0.0, 0.0, -1.6), 0.5,
    MatProp<> {
      .albedo = Color(0.1, 0.2, 0.5)
    }
  );

  auto left_sphere = DielectricSphere(
    Point3f(-1.0, 0.0, -1.8), 0.5,
    MatProp<> {
      .refractive_index = (1.50)
    }
  );
  // NOTE: inside left_sphere
  auto bubble_sphere = DielectricSphere(
    Point3f(-1.0, 0.0, -1.8), 0.4,
    MatProp<> {
      .refractive_index = (1.00 / 1.50)
    }
  );

  auto right_sphere = MetalSphere(
    Point3f(1.0, 0.0, -1.8), 0.5,
    MatProp<> {
      .albedo = Color(0.8, 0.6, 0.2),
      .fuzz_factor = 0.2
    }
  );
#

then when you add them you can just do:

  HittableList world;
  world.add(std::make_shared<decltype(ground_sphere)>(ground_sphere));
  world.add(std::make_shared<decltype(center_sphere)>(center_sphere));
  world.add(std::make_shared<decltype(left_sphere)>(left_sphere));
  world.add(std::make_shared<decltype(bubble_sphere)>(bubble_sphere));
  world.add(std::make_shared<decltype(right_sphere)>(right_sphere));
#

although idk why peter uses shared_ptrs for materials at all, when they are all unique. he should have used unique_ptr

rich dawn
#

I'll keep these in mind, though it is hard for me to understand atm 😂

rapid cargo
#

no prob. if you ever have any questions or w/e just hit me up. happy to help

#

I'll probably post my code on github soon once I finish the second book here

native shard
rapid cargo
#

Yeah I’m not saying it bothers me, like I said I use it. It just would be nice. If I need python code to go fast I’ll FFI it to something fast with threads by myself. But multithreaded GIL is a step forward

#

Or sometimes I’ll tie in a uvloop for some web bound stuff and make that go brrr

native shard
rapid cargo
#

Yeah you can’t beat the prototyping iteration time of Python with anything else really. The ecosystem is stupidly strong, including frameworks and libraries. OpenCV with Python versus C++ is like the difference between 10 minutes of work versus 2 hours of work. It’s just not even comparable. And those OpenCV libraries are FFI anyways so the perf (depending) is basically negligible

rapid cargo
#

@serene trellis lol

A5D9CF02-0A44-4D69-8930-24F76750337C.jpg
#

So many insane abstractions you need a book this thick just to document them all

calm marlin
#

who the fuck is robert?

languid totem
#

*Roberts confusedCat

rapid cargo
# calm marlin who the fuck is robert?

He’s a dickhead from Stanford that thinks by teaching his pupils how to program with abstractions at Stanford, he can also force the students to also have to buy his textbook. It’s a cute little conflict of interest. But it happens, a lot.

#

I mean it’s a decent book. But I always find it weird when the course syllabus is taught by the same guy who is selling you the books

serene trellis
#

Idk anything about the guy, but sounds like the "uncle" bob thing with "clean" code

rugged hound
#

@rapid cargo

#

did you ever have any uv map problems with bioshock?

rapid cargo
# rugged hound <@237801630873944064>

It’s a shader game so it doesn’t even support capturing normal buffers so lots of stuff is flat shaded. So to answer the question yes, but for entirely different reasons

rugged hound
rapid cargo
#

Manually. Modifying the runtime source to capture the right buffers and use them properly. Such as for lights as seen here #1144016019195691008 message

#

I’m hoping to upstream lots of these changes but I just haven’t got the time right now between work and life

rugged hound
rapid cargo
#

What game are you doing?

rugged hound
#

ghostbusters the video game

#

hashes are perfect

#

uvs are fucked

rapid cargo
#

Hmm. Do you have like an image or something of what they look like or what is not working? Is it just UVs that don’t work and everything else does? Does the logs say unsupported texture format, shaders, etc?

rugged hound
#

let me boot rq

rapid cargo
#

I def would. Might be some useful bits in there

rugged hound
#

shits banding

#

which log should i be checking?

rapid cargo
#

Any of them really

rugged hound
#

alrighty

rapid cargo
#

I’d at least try disabling alpha processing on the bad textures (you can also disable alpha globally)

#

And also try ignoring them, or use the debug menu to limit the draw calls until you see it doing the behaviour then see if you can set the materials to flat to debug if it’s some specific material being applied

#

The banding almost seems like it would be ignorable if coming from a texture or maybe it’s one big screen space texture that’s banding your whole view. It doesn’t look like it’s a UV being applied to every object

#

Almost like a render target ontop of something weird

rugged hound
#

theres like 6 different render targets

#

ive noticed that too

rapid cargo
#

Ah yeah that makes some sense. Iirc remix only looks at the one. But if it’s processing on another then flipping the render target result back out into the main it might be janky. I think you can ignore render targets, but otherwise I’m not too sure what the solution for that is. Without thinking on it

rugged hound
#

most of them are UI

#

but some just break the entire game

#

these dont really tell me anything

#

atleast to me

rapid cargo
#

Hmm the logs seem okay, but the FOV change between frames is a little sus. It does seem like it’s doing some texture target weirdness then applying it on top. I don’t think there’s any way to straight up say don’t accept any actions against this render targets, but you can ignore all the textures used in said render target rendering, and hopefully it won’t be as buggy

#

Or disable alpha on them, make them world space, etc

#

I think the UV mapping is probably fine if you get solid looking geometry and hashes in the debug

#

It’s more like a blending of textures from render target problem

rugged hound
#

its also assigning random textures to random shit

#

only alpha textures seem to work without everything breaking

#

im trying to figure out of its engine balogne or shaders or remix

rapid cargo
#

Damn rip. That could be a side effect of shaders or a texture caching thing they have. Bioshock suffers from the same and I had to patch the game to increase the cache size for the level as to not swap a texture back out to the cache and bring it back in compressed, which causes instability.

rugged hound
rapid cargo
#

If you really really want to figure out what’s going on, you’ll need to probably use PIX and capture a single frame with this behaviour and attempt to see why it’s doing with the textures and render targets

rugged hound
#

PIX?

rapid cargo
#

Yeah those hashes look good. The lack of character model is probably caused because of geometry skinning and not textures

rugged hound
rapid cargo
#

PIX is a legacy graphics debugger for d3d9

rugged hound
#

when a ingame light is shined on it

rugged hound
rapid cargo
#

#reverse-engineering message

#

Set that up without remix in a vanilla game, and attempt to capture a frame or a few of them with the F12 experiment

#

Then you’ll get a per call trace of exactly how it’s rendering your scene

#

You’ll be able to see it construct it bit by bit

rugged hound
#

sick alrighty

#

are you able to assist in helping if i am feeling mentally slow at all

#

thanks for all the help already though

rapid cargo
#

Probably, but i just might not respond right away. Ping me in your game channel if you have any other questions. Would probably be better to have this convo over there

rugged hound
#

okay thank you

rapid cargo
#

Yeah np

sour gulch
sour gulch
#

Hey @honest badger I'm running into an issue where texture hashes change with each reload of a map. I've taken captures after each map load to compare the exported dds files but they are the same - byte for byte, yet have different hashes.

Example random texture on first load: ABCD - second load: EFGH - third load: IJKL - fourth load: IJKL
After a restart, the hash will be ABCD again (but not 100% guaranteed).

I think it only affects textures that contain some emissive part in them .. any idea what might cause that?

Second issue: Vertex normals are packed (ubyte4). Do you think its feasible to unpack them on the remix runtime side or would that have to be done on the bridge before sending them to the runtime?

📎 0A0DEEA9A78BB952.dds 📎 3FCB458049C8A891.dds
honest badger
# sour gulch Hey <@617500777191047168> I'm running into an issue where texture hashes change ...

The actual image hash is calculated here:
https://github.com/NVIDIAGameWorks/dxvk-remix/blob/main/src/d3d9/d3d9_common_texture.cpp#L683

and the DDS save happens here:
https://github.com/NVIDIAGameWorks/dxvk-remix/blob/main/src/dxvk/rtx_render/rtx_asset_exporter.cpp#L95

At a guess, there's something different in the hashed buffer that doesn't make it to the final DDS. you might try break pointing in that function for the different hashes you're getting, and seeing if there's anything different in the image argument.

honest badger
#

but I suspect bioshock isn't packing the normals in the same way Remix does

#

It may be better to have a pre-process that just unpacks the normals (similar to the skinning pre-pass)

#

We convert from a 32 byte uint to a normal using the octahedral to sphere method. They're probably using something more like 15 bits for x, 16 bits for y, and 1 bit for z's sign, at a guess.

sour gulch
honest badger
#

facepalm they're using 8 bits for each direction, and then just wasting 8 bits for a 4th component?

#

that's just wasteful

#

Are they doing that through fixed function, or do those go to some vertex shader?

sour gulch
honest badger
#

Does our vertex shader capture feature work for it?

sour gulch
#

Toggling capture normals from shader does not seem to make a noticeable difference .. I'm honestly not sure. It is really noticeable on bsp but that now renders via fixed function for some reason

image.png
sour gulch
sour gulch
#

Update: I've fixed some of the vertex normal issues by unpacking them and modifying the vertex buffers on the fly. Happens on each draw for the viewmodel and only once for static buffers such as bsp. Also fixed some minor other issues

rapid cargo
#

You know, you could have messaged me and we could have worked together on this or something, but I come back after being away for a few months to see this is a little disappointing and quite a slap in the face to the months of work I put into this. I think I'll be checking out of this project for now.

rapid cargo
sour gulch
sour gulch
rapid cargo
# sour gulch Sorry didn’t want to disturb you in whatever you were doing and I thought I coul...

I understand, and fwiw I'd like to work on something like this with you as well, at the least to make sure you're not duplicating efforts and vice-versa. To be honest I was just a little taken a back that you just posted a link to your repo -- if this is a game you'd like to tackle as well I was just surprised that you'd just attempt to do it from scratch without maybe chatting about it first. But I also didn't know you didn't want to disturb me, so that's fair.

I think if we work on this together I'll need to merge several levels of our projects together and im not sure what the best way to do that is right now, but I can start picking away at some pull requests, as I follow a somewhat similar hierarchy, but with a lot of specific differences too. I need to spend some time seeing where exactly you are at and what I can even port over, assuming you want to actually do a complete mod for this game.

native shard
rapid cargo
#

well I mean that's fair, but also sending a message takes 5 seconds (I also don't think NFS is a fair comparison to this, those aren't compatibility mods, the game already works, those are more subjective)

languid totem
#

WATBULB!! Welcome baaaack! blobhuglove

rapid cargo
#

Hi!!!

sour gulch
rapid cargo
plucky cove
# sour gulch Pushed my bioshock stuff to: https://github.com/xoxor4d/remix-comp-projects

Installed this on the GOG version of the game, but I just can't get it to work for some reason.

RTX-Comp Debug Console just says: [INIT FAILED] Unsupported Game or Version of the Game!

Remix hooks, there's no cursor visible, only UI elements render (also, when I pause and unpause, the pause menu will stay on screen with other UI elements render ontop). Imgui also doesn't open at all using F4 or F5.

I followed the guide, made sure every file is where it says to go, so I'm a bit lost as to what's going on. I'm on GOG, BioShock 2007 v1.1, clean install, but no luck unfortunately. Any idea what's going wrong?

📎 bridge32.log 📎 bridge64.log 📎 remix-dxvk.log
fickle moon
#

this never got posted here i guess

fickle moon
plucky cove
calm marlin
#

How far into the game does the mod cover? Does the intro work?

glad birch
#

i got it to work but it crashed on the splicer scene

#

when you get to rapture

#

also it only works on a GOG release which is not commercialized anymore

#

2007 release from steam will not work