#Tomb Raider: Legend

1280 messages · Page 2 of 2 (latest)

naive island
#

there are many games that don't pass the normals properly. all of those games do use vertex shaders for rendering the characters

slate oasis
wind current
#

Poor barnyard 😅

#

@naive island does barnyard also have the lighting rotation problem?

naive island
#

mm can you give an example?

wind current
#

Like do the lights rotate with the camera?

naive island
naive island
#

replacement meshes also have this issue

#

FNV and Skyrim too unfortunately, also for the normals issue

wind current
#

It seems to be (imo) a side effect of console porting

#

Me thinks

naive island
#

it seems to happen in any game where everything is rendered through vertex shaders

#

i don't know enough about the console porting process to really weigh in on that though

wind current
#

Oh wow really? That’s severe. I mean in my case here they do really strange things with the transforms so that could be why, but I also haven’t ever seen a shader game work completely properly with remix so I can’t really determine if it’s something on remix’s side which can be solved or not. The problem I see here is when rotating the camera both the world and view translate or rotate. And since lights positions are derived from the objectToWorld transform, that means so long as the world transforms so does any light object

naive island
#

that sounds exactly correct from what i've gathered. mostly from what Mark has told me lol

wind current
#

I would have thought that fusing the position to the world or view would fix that, but if both of them rotate. You are really screwed I think

naive island
slate oasis
#

If you have game code access, I think there's actually a d3d9 function you can call to just tell Remix where the camera is, which should also help with fixing up those matrices

wind current
#

I don’t have code access. But pretend that I do, I can call anything. So if you know the name ….

slate oasis
#

basically set up the fixed function transforms so that you can draw meshes with it, but then don't actually draw them

wind current
#

Currently I just do SetTransform with its worldToCamera and CameraToWorld transforms

#

So I think I already do that

slate oasis
#

so yeah, sounds like you do it

#

but I guess it's not interacting with the VS draw calls correctly 😦

wind current
#

It’s very painful 😣 and kinda stretches the limits of my brain. But if you move the camera to the left, both the world and view transforms rotate, so that means there is no possible fixed 0,0,0 point unless you track the displacement of the transform from the original position

#

So what I tired to do was exactly that, take the displacement of the matrices per frame and subtract that from the light position

#

It works, but unless I can get deadly accurate with FP rounding, it always jitters

#

And flexes, etc

#

This could somehow be solved if you could bind a light to a mesh position

#

Then when the mesh position rotates with the world we bind it to the new mesh position, but I need a way to send that new position of the mesh object to remix

#

Or something like that

slate oasis
#

I wonder if you could futz with the transform being sent to the vertex shaders

#

instead of trying to reverse them with a world matrix, just remove that component from the vertex shader's input matrix entirely

wind current
#

hmm, I actually never tried, but I can.
The way this game passes it to the shaders (just for context) is the fairly standard SetVertexShaderConstantF, on register index c0, which is the WVP matrix (pos). So when it hits the shader (or d3d9 api) its in the fully multiplied form, but I can pass in my own if needed by hooking this call.
Right now I've been able to reverse engineer the original world and view transforms (the game calls them view: wcTransform, world: cwTransform). So I pass those into D3DTS_WORLD and D3DTS_VIEW. Then for projection, I just use a standard projection matrix with the near/far reverse engineered (0.98, 9.8e8)?? So I think I have the correct individual matrices now. So I could make my own WVP and just make World an indentity matrix, which I have not yet tried. but unless my projection matrix is perfect (I can't find the one in the game), it might be a little buggy ....

#

I vaguely remember attempting something like this in the prior weeks, to find out if I do use a custom world matrix that I need to translate it to some unknown amount because the game doesn't actually use 0,0,0 to instance the level

#

disclaimer: I only know what im doing sometimes

slate oasis
#

can you just pass an identity matrix to the shader, and set the draw call's object matrix separately?

wind current
#

@slate oasis I got timed out

image.png
#

😅

#

those damn dirty flags

slate oasis
#

might be relevant

wind current
#

the game by itself does not render at all with the WVP passed by the shader, its not until I make them dirty by setting them manually (via SetTransform) does it kick off, so this points strongly towards remix not being able to decompose the WVP from the SetVertexShaderConstantF call, because afaik that is literally impossible without priori data

slate oasis
#

If you're setting all the matrices with setTransform, you can try to just make the game pass an identity matrix to the actual shader

wind current
#

to the shader or the FFP state? the setTransform sets the FF transform state, to set the matrix as identity in the shader I need to provide the W * V * P myself (via the set shader constant call), and then im not even sure if remix is respecting those transforms currently. but yeah, I've tried just passing a identity matrix via SetTransform for the world, and it sort of works, but everything is rotated by 180 degrees ....

slate oasis
#

just try passing an identity matrix to the shader (so that it doesn't do much of anything) and pass the actual matrices in using setTransform.
basically make the vertex shader do less, and use the FFP functions instead

#

not sure if it'll work, but if it's easy to set up then it's worth a shot

wind current
#

me passing identity matrix to shader for world

wind current
#

the transforms I found must not be right, because this does literally nothing:

HRESULT d3d9ex::D3D9Device::EndScene()
...

  // Update the transforms every single frame
  m_pIDirect3DDevice9->SetTransform(D3DTS_WORLD,      &cdc::GameState->world);
  m_pIDirect3DDevice9->SetTransform(D3DTS_VIEW,       &cdc::GameState->view);
  m_pIDirect3DDevice9->SetTransform(D3DTS_PROJECTION, &cdc::GameState->projection);
  cdc::GameState->isFirstFrame = true;

  return m_pIDirect3DDevice9->EndScene();

D3DTS_WORLD, and D3DTS_VIEW here are meaningless, they can contain whatever and it wont matter, its only if the projection is set will it begin to render. this doesn't make any sense.

#

so remix isn't able to understand the WVP sent to the shader via the SetVertexShaderConstantF call, but as soon as you pass it a projection it just randomly works

#

and you only need to call it just once

#

all attempts of only passing a identity to the shader have been fruitless, its just triangle soup garbage:

// Register Indexes:
// c0  - XYZ     (x, y, z, w) [World * View * Projection]
// c4  - DIFFUSE (r, g, b, a) [Vertex Colors]
// c8  - TEX1    (u, v, w, ?) [Texture Coords]
// Optional:
// c12 - TEX2 
HRESULT d3d9ex::D3D9Device::SetVertexShaderConstantF(UINT StartRegister, CONST float* pConstantData, UINT Vector4fCount)
{
  if (StartRegister == 0) {
    D3DXMATRIX ident;
    D3DXMatrixIdentity(&ident);
    cdc::GameState->updateMatricies(); // just updates cdc::GameState with matricies from the game engine, which we use in EndScene with SetTransform
    // auto wvp = cdc::GameState->world * cdc::GameState->view * cdc::GameState->projection;
    auto wvp = ident;
    return m_pIDirect3DDevice9->SetVertexShaderConstantF(StartRegister, wvp, Vector4fCount);
  }
  return m_pIDirect3DDevice9->SetVertexShaderConstantF(StartRegister, pConstantData, Vector4fCount);
}
#

if I use the WVP I've multiplied there from matricies found in the game (the commented bit), it results in the video above

#

If I pass in only a identity matrix as shown in the code above to the shader constant, but then pass in the matrices grabbed from the game via SetTransform it results in this:

#

in fact, and again, setting D3DTS_WORLD and D3DTS_VIEW in any case does absolutely nothing. if we pass in the original pConstantData to the shader for the WVP, and only set a projection manually with SetTransform, everything magically just renders.

#

anyways, this seems to be a bug, or a non-obvious and admittedly annoying design choice, because remix needs to pick one or the other. it cant just be expecting a transform to be provided from the manual SetTransform call, then use the shader provided WVP for everything else. No game does that (the reason why remix has to is because decomposing a WVP is literally impossible without some kind of known information, like for example the projection transform)

#

I get that supplying a transform manually sets the dirty flag for the matrices which might signal to remix something I dont quite understand, but it needs to choose. use the transform supplied by the shader or don't.
I don't see how me supplying a projection transform on one single frame causes everything to magically just work when it works in vanilla DXVK with the generic shaders without having to lift a finger. its beyond comprehension, real games dont use shaders and call SetTransform, its illegal.

If this is what remix is expecting (because it needs access to the individual transforms), it could make a ton of shader based games just literally start working out of the blue by simply providing a generic projection transform given you know the near and far parameters. Because thats all I've done here at this point for it to render (transform wise, and albeit with this translational bug). The shader formats are textbook pass through, like many other games, they basically emulate FF POS | NORMAL | TEXT, as that is the declaration of the shader, and each rendered object instance requires setting the constant registers for those parameters. its literally exactly the same concept as fixed function, but it passes the vectors through constant registers and buffer source instead of doing SetFVF and buffer source.

wind current
#

So this really goes against "shaders" dont work with remix, because they evidently do if you can give it a single transform which it can use to understand the one passed by the shader. Like I mean this is VS_1_1.

#

But in the case where a game is always rotating the world and view passed to the shader (dozens of games have been reported to do this, good ones too), remix will have no zero (0, 0, 0) static reference point, because that relative point is always changing. So remix needs to support binding objects to the positions of meshes per frame with an anchored offset, if it wants a generic approach that will work. (Maybe I can implement this using the API to query the position of a mesh? I could query the engine to ask for the position of an instance, but those never change)

wind current
#

unfortunately these kinds of games will probably wreak havoc on the denoiser since the position of the light would change so much on every movement, possibly confusing it or having the bounce become inaccurate or fuzzy, which ive seen

wind current
#

ffs 😂

image.png
#

this is actually a perfect example image. the game uses two different transforms. the mansion is based on one, and lara and a few random assets based on another, here im trying to manually transform it

slate oasis
#

Well, certainly interesting results.

Remix is expecting fixed function drawcalls - the vertex shader support we do have is something that was thrown together because an engineer had an idea for a quick / easy way to make it kinda work. In theory getting vertex shaders to be mostly supported shouldn't be that big of a problem - it's the pixel shaders that are really troublesome to support.

In practice I really don't know enough about this to help here. Lemme ask around internally

slate oasis
#

There are a lot of games that mix vertex shaders and FFP, so they set up the camera matrices for both routes. I think the vertex shader support leans on that to figure out the correct camera.

slate oasis
#

If we have a single camera set up, I believe we'll try to use that camera for all draw calls. You should check out CameraManager::processCameraData for an idea of what we do with those camera matrices.

#

I also found a comment in D3D9Rtx::prepareVertexCapture:


    // 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;
#

basically - the viewToProjection matrix is only set by FFP draw calls, and so shader draw calls just use the matrix set by a FFP call. I believe the only place we set ViewToProjection is in D3D9Rtx::processRenderState

grand linden
#

If I could chime in here.

real games dont use shaders and call SetTransform, its illegal.
Actually, they do. Sometimes its just a bug on the game devs part, but othertimes its because the game will submit some draw calls as shaders, and others as fixed function.

If a game submits a shader based draw call but also happens to call SetTransform its certainly not illegal, its actually just that under regular D3D9 the SetTransform calls are benign. When a shader is bound for the vertex stage, those transforms are completely ignored.

As for how the remix shader reverse engineering works, we inject some code at the end of the vertex shader - this injected code uses the fixed function world/view/projection matrix (inverted) applied to the SV_Position attribute from the shader. This attribute by the D3D9 spec requires a 4 component vector in containing the position of a vertex in projection space. And so by applying the inverted matrix we can return this position to the "world-space" assuming the values set by fixed function transform are indeed sane.

In summary this means, you should keep the games shader constant buffer the same, do not modify and instead, pass some correct values for View and Projection matrix via the SetTransform API.

Why do it this way? Well because some games have very complex vertex shaders, we cant assume they are just doing a simple MVP transformation - they could be doing skinning for instance (like in the case of characters), or some other procedural movement (like in the case of grass/leaves).

wind current
#

illegal may have been the wrong choice of word, what I mean to say is "useless". What I also mean is using SetTransform after SetVertexShader is called (with a valid pointer) is probably going to be, as you say, benign. a bug.

In summary this means, you should keep the games shader constant buffer the same, do not modify and instead, pass some correct values for View and Projection matrix via the SetTransform API.

this still doesn't solve the problem. if I leave the shader constant buffer the same, then I need to use the transforms the game provides. if the game is always rotating the world and view transforms, then I don't have a static reference, and consequently any remix placed object transforms with the world and view. If I use an identity matrix for the world, that identity matrix only works if I modify the shader constant buffer register. Setting world transform (as identity) via the SetTransform call does absolutely nothing (while leaving the shader constant buffer alone).

wind current
wind current
#

This attribute by the D3D9 spec requires a 4 component vector in containing the position of a vertex in projection space. And so by applying the inverted matrix we can return this position to the "world-space" assuming the values set by fixed function transform are indeed sane.
this makes alot of sense now, as to why setting the projection works 🙏. thanks

wind current
#

a bit confused by this. So I leave the shader constant buffer the same, use a simple identity matrix and a projection transform on a single frame:

  if (cdc::GameState->isFirstFrame++ == (60*5)) {
    D3DXMATRIX ident;
    D3DXMatrixIdentity(&ident);
    m_pIDirect3DDevice9->SetTransform(D3DTS_WORLD,      &ident);
    m_pIDirect3DDevice9->SetTransform(D3DTS_PROJECTION, &cdc::GameState->projection);
  }

Projection created using:

  // Generic projection matrix
  D3DXMatrixPerspectiveFovRH(
    &cdc::GameState->projection,
    D3DXToRadian(DEF_FOV_DEG),
    (FLOAT)(rc.right / rc.bottom),
    DEF_MIN_DEPTH,
    DEF_MAX_DEPTH
  );

Use world transforms is selected. World transform never changes. yet the lights still translate with the (world?)-view provided by the shader. If I try adding a view transform provided by the game for D3DTS_VIEW, same result.

soft bay
#

Without the FOV slider, I would've never realized how much they worked on this level design wise, lots to remix in this level peepoBlushReallyHappyDank

Tomb_Raider_Legend_Screenshot_2024.11.13_-_06.10.36.27.png Tomb_Raider_Legend_Screenshot_2024.11.13_-_06.10.47.92.png
wind current
#

getting a little further. I can make the level room object associated with a static world transform, so when remix grabs the lightToWorld transform it stays still. But as you can see, several objects are rendered based on the view transform, which also seems to rotate. So this doesn't really work .. because I will eventually need to rotate the world to provide the camera rotation and movement ... but remix transforms the position of the light based on the world transform ... so ... uhhh ... not sure how its going to have a zero reference for the light position if both rotate.

#

I would have thought this would have just normally worked, since the light should rotate with the world to stay visually in the same position ... but I guess this isn't happening correctly (the position of the camera becomes 0,0,0 if we rotate the world how the game wants it, which doesn't really allow for correct light translation)

wind current
#

something I am going to try is getting the matrix for the world during the first frame, so when subsequent frames produce a new world matrix to rotate by for the drawcall, I can have a reference to translate the light based on the net position difference both matricies transform the light by

wind current
#

the only way I was able to do the above though was by modifying the SetVertexShaderConstantF call directly. Doing world ident via SetTransform does nothing, but it works if you do it via SetVertexShaderConstantF.

In summary this means, you should keep the games shader constant buffer the same, do not modify and instead, pass some correct values for View and Projection matrix via the SetTransform API.
is wrong.

sullen solstice
#

Uh.

#

Sure.

#

I'll keep that in mind.

wind current
#

Oh I bet

craggy star
#

Unfortunate

wind current
soft bay
#

Watbulb is cooking! peepoBlushReallyHappyDank

craggy star
wind current
#

ye, was just gettin the data in, am doin that rn

wind current
#

they render the room zip is in twice ffs

soft bay
woven haven
#

Average Remixer be like:

sullen solstice
#

Me when slightly incompatible game

wind current
#

need to work on some scaling issues, but should work for a few things. spot lights with shaping need more work to invert the cone shape and direction based on the world

#

auto pos = D3DXVECTOR3(matf._14, matf._24 * 0.75, -matf._44 * 0.75);
🙃

#

also im not sure the best way to handle letting the toolkit do this since I'm changing the position of the light every frame. I'll either have to extract their reference positions from the mod files, or pass a per-frame transform to remix to adjust the light positions by

wind current
#

@soft bay for now just give me your mod files and I will extract all the reference positions of the lights per level. so it should appear like it does in the toolkit until I can think on it some more

sullen solstice
#

Looks like clearly some data is being sent to the dentist wrong causing the artifacting.

wind current
#

probably a combination of ultra performance DLSS, and the fact the scaling makes it so the precision isn't 100% correct for the light position every frame. I also currently set the position of the light one frame behind the current frame causing a slight delay

sullen solstice
#

Are they accurate?

wind current
#

DLSS extracts the motion vectors from the scene already, so yes

#

if you mean the vectors for the light, no not completely

sullen solstice
wind current
#

for what?

sullen solstice
#

Motion vectors

#

I have a feeling that they're incorrect

wind current
#

I dont understand what you mean

#

what motion vectors do I set incorrectly?

#

do you even know what I set?

sullen solstice
#

No. I don't know what you set. But you can check the debug visualization to see if they're behaving correctly.

#

Because those shadows should not be that blurry during camera moves

#

There's clearly something going on to bug them like that

#

And I suspect it's the mvs

wind current
#

I dont really see what you are referencing either than the shadow moving in the y direction ever so slightly which is the scaling issue I referenced, which is something I am deliberately doing and understand

#

do you mean the shadows before I enable ray reconstruction?

sullen solstice
#

Yes

wind current
#

the motion vectors only appear when ray reconstruction is enabled

sullen solstice
#

No, the non RR denoiser also uses motion vectors

#

So does dlss

#

And so do the other parts of the path tracer to keep the image stable

#

It's very important to make sure they're working as intended

wind current
#

I know, what I mean to say is the motion vectors only appear in the debug view when ray reconstruction is enabled

#

there is no DLSS Motion Vectors setting. Its only called "DLSS-RR Motion Vectors"

#

in any case the motion vectors is not something I can influence I dont think 🤷‍♂️ (I will look into it more)

sullen solstice
#

I don't know if anything changed, but there's a view called virtual motion vectors and another one called object motion vectors

wind current
#

oh, ok lemme see

sullen solstice
wind current
#

sure

sullen solstice
#

Idk why we're arguing kek

wind current
#

idk im not arguing, im just confused, I also dont really understand what I can do if its not working

#

like do you have a suggestion?

sullen solstice
#

I wish I did, but I'm not a reverse engineer. All I can do is point to potential areas for improvement.

wind current
#

fair enough, I didn't even know there was a debug view for that so its useful to know

#

at least it seems to work better when RR is enabled.

#

ill make a video

#

this jiggling I think I can fix

image.png
#

Im doing a dumb and using the last frame's motion vector essentially

sullen solstice
wind current
soft bay
#

OMGGGGGG NO WAYYYY!!! BLANKIES BLANKIES

#

Watbulb you’re a genius FeelsWeakMan

soft bay
#

Watbulb do you have a kofi or something like that? BLANKIES

wind current
#

Nop. No moneys required. I really appreciate it tho. Maybe once it gets released or I work on more mods I might.

soft bay
#

You're the best watbulb, really really appreciate the work you're doing pepehug

wind current
#

It’s been fun. I mean I don’t do graphics or anything like this for a living, it’s more a hobby or interest I guess. I’ve learned a lot doing this. I still need to provide you a way though to get lights into the scene.

#

I think I’ll probably need to expose some bridge api method to grab the positions of them from your mod file

#

Or send a new transform for the lights to remix by hash

wind current
#

it seems like the position update of it is always one frame behind, yet I send all the correct position information per frame (well before Present)

#

I thought at first it was camera view acceleration thing, so I made sure to round off any smoothing issues after the mouse is let go while it settles the world, makes it a little snappier but still looks a frame behind

slate oasis
#

Are you only relying on the debug visualization to track the light position?
That is drawn in the UI thread, which has an entirely separate draw loop, on a separate thread.

wind current
#

Ohhh that makes more sense. Yes I am.

slate oasis
#

I would be very surprised if the debug light visualization was perfectly lined up in terms of frames

wind current
#

But only for debugging it (visually), the actual position comes from the world (simplified explanation, but it’s directly based on the position on objects in the world per frame)

#

I’m referring to the jiggle on the shadow on the floor

#

26 seconds

#

I mean if you’ve never seen this behaviour before it’s probably something I’m doing

#

Just trying to get your thoughts

slate oasis
#

sorry, juggling multiple things right now

wind current
#

Np take ur time

placid bluff
#

light information submitted through the api is indeed a few frames behind

wind current
#

Here I’m just doing it via d3d9 AddLight stuff so I’m not using the API afaik

#

I’m just doing what a game would do

placid bluff
wind current
#

Ah yeah wow that’s the behaviour I see too

#

I figured the UI debug would be a little behind, but it does really feel a little behind physically

#

Could have something to do with the fact I change its position every frame instead of somehow passing a new transform for a specific light hash. Maybe that would be better, but afaik there’s no remix API based way to do that for an existing light

#

Could be wrong

placid bluff
#

I never bothered testing things myself but you could round off the light's floating point coordinates/transform to prevent its hash from changing every frame. however I don't think it'd actually fix the issue

slate oasis
#

Hmm, most of the lights in Portal were static, so we may not have much coverage... but there also dynamic swinging lights in the recent HL2RTX trailer, and those didn't look like they had any lag at all.

Is this one of the games where the camera is static and the world is moved around the camera?

wind current
#

yes

#

the camera also moves sometimes, but yes.,

slate oasis
#

ah, just to make things extra complicated, huh

wind current
#

indeed 😛

#

I kinda found a generic method to handle it by doing some heuristics on the constant transforms sent to the shader, but its finicky

slate oasis
#

I'm pretty sure we have dynamic lights working with no wiggle in source engine games, but those have mostly been replacement lights that were attached to meshes. I can't actually think of any mobile lights that came from d3d9 off the top of my head

#

Have you tried playing with any of the RtxOptions about anticulling for lights, like rtx.numFramesToKeepLights and rtx.antiCulling.light.numFramesToExtendLightLifetime?

#

hmmm, there's code in LightManager::dynamicLightMatching that tried to identify dynamic lights and track them across frames. That's based on rtx.uniqueObjectDistance, so you could see if this persists when you crank that way down

#

(turning it down too low will probably cause other problems, but if it fixes the delayed wiggle then it'll isolate the bug)

#

Having you tried drawing these lights with the Remix API yet?

#

(Also, complete side note, but sorry your existing PRs are taking so long address)

wind current
wind current
wind current
#

probably will end up going with that because my other plan was to essentially have remix tell me the positions of the lights from the mod file

#

(because this game doesn't ever create lights with d3d9, so I need some way to get them from some data store )

wind current
#

its all just from ontop the d3d9ex api

slate oasis
wind current
#

and after movement slows

slate oasis
#

I don't see a bug when reading through the dynamic light matching code, but I am suspicious that updateLight doesn't seem to be setting the light that gets kept to have the transform from the light that's getting deleted... but I'm having trouble tracking which light is new vs old

placid bluff
#

fwiw everything in that skyrim clip is done via remix's api. I made extensive modifications to remix's code so I can't say whether it's my doing or not. having another tester would be better

wind current
#

cool :). sounds like I should use the API and double check everything or a/b test the lights using both

wind current
wind current
#

@slate oasis if a game uses a shared vertex buffer between frames for objects, that could cause the meshes to be unstable, or is that incorrect?

#

It just seems that vertices that are highlighted pink by the option to visualize them are quite unstable upon world movement

slate oasis
#

Not sure what option you're talking about when you mention highlighting them pink tho

wind current
#

Hmm, I’ll have to dig into it more then. That makes sense so I don’t think it’s necessarily related, but not sure.

Sorry I think I confused the name. It’s called “highlight legacy meshes with shared vertex buffers” under (Enhancements? None are enabled tho)

#

the post which isn't shared always stays green 🤔

#

or some area of it atleast

slate oasis
#

ah, in that case, I believe that means the vertex indices of all of those meshes would be changing every frame, which is why their hashes are so unstable. It means we're having to rely on a similar heuristic to the lights, for trying to find similar instances to track them across frames.

#

It's entirely separate code AFAIK, but the logic is similar. Maybe we have the same bug in both spots, or in some shared utility they both depend on.

#

What happens (to both the lights and the wobbly meshes) if you turn the search distance way down? I expect the actual lighting quality will degrade a lot if we can't track matches, but I'm curious if it'll fix the wiggle

wind current
#

for the lighting situation the search distance doesn't seem to have an effect. I'll check the hash stability in a couple hours

slate oasis
#

Hmm, I suppose the problem is somewhere else then... you tried putting it all the way down to 0?

wind current
#

yeah, doesn't seem to do much. but I did just notice something, if I make the view fused to the world transform it seems to update immediately

#

I can't debug it properly right now because all my transforms are fused to the view currently to make it display properly

slate oasis
#

huh.. I should really read up on the fused world view stuff to understand what that is actually doing. never had to touch that code

wind current
#

I barely understand how it works 😛. I just set it to view fused and provide a static ident transform via SetTransform for world, and a basic projection and view transform. I dont think remix even uses these though outside of the projection transform because im using shaders for all the draw calls 🤷‍♂️

#

I can modify the view transform with SetTransform and it does offset objects in the view, but not the real game with path tracing off

slate oasis
#

sounds like you know more than I do about it right now

wind current
#

so remix does understand them

#

but since I can't properly reverse engineer the actual transforms the game uses I just leave them blank. I think the reason why I have to supply a projection transform to kickstart the rendering is to help remix do the heuristic to get the initial camera position

#

because otherwise it doesn't render at all just with the position provided by the shader

wind current
wind current
soft bay
#

It's so pretty!! AAA

sullen solstice
#

That kinda beautiful, ngl

icy yacht
#

I'm so excited for this. As soon as we have a stable, ready to mod version I'm soooo gonna mod the hell out of this game

wind current
wind current
#

need to find the aabb frustum test function to disable culling then I think it will be passable

#

I did find a method to extract the actual positions of lights from the shader directly since it passes a set of vectors on a specific shader for their position. So I can see about integrating those into actual D3D9 lights to see where they were in the actual game

soft bay
#

AWESOME!!! I'll dm you some gameplay, very exciting dance

dusky hawk
#

looks like that one cod mission

#

the russian mission

soft bay
#

Surprised how real the little light texture in her eyes holds up, I can't tell if I should remove it or not Looking

Tomb_Raider_Legend_Screenshot_2024.11.26_-_22.12.09.90.png
#

It does stickout in dark rooms though

wind current
#

sometimes it makes her look like she has laser beam cat eyes in dark areas

sullen solstice
soft bay
wind current
#

wow thats crazy 😍 . looks great. I'm writing a lot of code for this bioshock project I'm hoping to transfer over to TRL, which should make it alot easier to fix some of the alpha issues this game has as well. Stuff like hashing geometry and being able to bind the light to it's specific object transform every frame. I think I can make the hashes more stable as well.

soft bay
#

EEEEEEEE so exciting, TRL and Bioshock are on my top 5 games of all time peepoCheer Can't wait to see more, keep up the good work! And take your time, I'm in noooo rush hierghYes

wind current
#

Sounds good :). I'm hoping to be done mostly with a beta for bioshock come christmas (at least for the first few chapters), then I'll begin backporting all that to TRL. While building this I've been trying to build it into a framework style thing that makes it easy to abstract any other game into it's hooking engine.

#

Once I feel like it does enough useful stuff I'll open source it, right now it changes alot and I refactor it a bunch for it to be useful. of course people can always ask for the code if they need

soft bay
#

SOO COOOL! Can't wait to see what other games come out of this, this'll be very useful for Remix pepoSip

wind current
# soft bay

are they supposed to look that blocky? man, I really need to figure out mapping normals from the shaders

soft bay
#

Oh yeah, it's a kids exhibit about king arthour, they're wooden figures PeepoGiggles

wind current
#

oh okay lol

craggy star
#

I mean, look at Lara

#

Btw, @wind current turns out there is an actually matching pdb for the demo of the game

#

It's actually nice

wind current
wind current
craggy star
#

I think steam has a demo as well, should be the same

wind current
#

oh nice

#

thanks

craggy star
#

Should be 12th of May build

wind current
#

finally found AABB setter:

int __thiscall sub_ED1B20(__m128 *this, __m128 *a2, __m128 *a3)
{
  __m128 v3; // xmm0
  __m128 v5; // [esp+10h] [ebp-10h]
  v3 = _mm_mul_ps(_mm_add_ps(*a2, *a3), _mm_shuffle_ps(0x3F000000u, 0x3F000000u, 0));
  *this = v3;
  v5 = _mm_sub_ps(*a3, v3);
  this[1] = v5;
  return LODWORD(v5.m128_f32[2]);
}
#

min/max

honest hull
craggy star
#

Considering it's called CullingAABB::Set, i'd say not much

image.png
honest hull
#

Ooh, so just slap huge negative/positive numbers to min/max vectors and let it roll

wind current
#

That or I just walk it back to the intersections, its a good starting point

honest vapor
wind current
#

Yes, I’m working more on this project this month

#

Haven’t been able to work on this for the last few months though, sorry

honest vapor
#

oh no need to apologize; I was reading through the history here and I'm impressed by your commitment. I'm glad you haven't given up 😅 Thank you!

#

wish I knew more about graphics programming to help more with this; I can help if you need another hand to help with programming otherwise tho 😄

soft bay
#

omg tomb raider legend with hdri skydomes

#

going to look for 1 for bolivia

near thicket