Jump to content

  • Log In with Google      Sign In   
  • Create Account

L. Spiro

Member Since 29 Oct 2003
Offline Last Active Yesterday, 11:05 PM

Posts I've Made

In Topic: Chess moves

Yesterday, 09:54 PM

That is very disappointing. I guess I'll have to find some other programmer use for a 5TB external hard drive.

A very long list of prime numbers.

L. Spiro

In Topic: Handling Tall Shadow Casters Culled By View Volume

Yesterday, 05:08 AM

All lights have their own frustums.
Directional lights have no near planes (unless there are cases in which you want to prevent far over-head objects from casting shadows) and thus gather all objects that could cast shadows into the view of the player from infinitely far away.
I have written an article on this.
Tutorial: Tightly Culling Shadow Casters for Directional Lights (Part 1)
Tutorial: Tightly Culling Shadow Casters for Directional Lights (Part 2)

L. Spiro

In Topic: Cannot understand behaviour of BoundingFrustum created from projection matrix...

18 December 2014 - 06:40 PM

If I remove the part where I multiply projection matrix by rotation matrix, Contains method returns expected CONTAINS value. If I leave it, Contains returns DISJOINT value.
My point should lay exactly in the middle of my frustum. In my belief rotating frustum shouldn't change the result of intersection test.

Rotating a projection matrix makes no sense, so there is no reason to believe you should get anything but DISJOINT.
Your results are exactly as expected, because you’ve basically just mangled your frustum.

To correctly rotate a frustum the rotation must be done on the view matrix which would have your multiplications in reverse order (in the order shown by Alundra).
However you would still get DISJOINT since that would rotate the frustum around [0,0,0] and the point you are trying to test would be behind it.

Stop doing what you are doing. You are not rotating the frustum—for all intents and purposes, what you are doing is “undefined”.

L. Spiro

In Topic: Swap chain rendering to multiple views

18 December 2014 - 06:25 PM

2 swap-chains and a single back-buffer?  Swap-chains have their own back-buffers, so I don’t know about what you are talking, but it doesn’t matter because it seems you’ve just jumped through a million hoops to avoid a problem that doesn’t exist.

This means I can resize my views freely and not worry about losing the device.

You can already do that while using buffers that are correctly sized for each view. You only have to reset the device when swapping between full-screen and windowed modes (not an exhaustive list), so it isn’t clear what you are trying to accomplish here.

I'm using swapchains because the view(ports) in the c# client can be resized and with swapchains, you can resize them and reset them without losing all your loaded resources.

This has nothing to do with swap-chains. You aren’t going to lose anything if you just stay in windowed mode, regardless of swap-chains, and swap-chains are necessary to Present(). They don’t solve a problem, they facilitate necessary functionality.

I don’t understand your setup entirely, but it seems to be the result of misunderstanding that resizing anything is going to cause you to lose your device.
#1: Stop misunderstanding that and implement things correctly instead of using work-around hacks. This will solve all of your problems immediately.
#2: Stop running away from lost devices. The full list of things that can cause the device to be lost is intentionally left unspecified so that people don’t make assumptions as to what can cause it and thus will implement proper handling of such a scenario. It is also trivial to restore resources after a lost device, so there is really no reason not to handle it properly.



L. Spiro

In Topic: Unreal Engine 4

18 December 2014 - 05:48 PM

Did you try their forums?



Or the first return when searching for “Unreal Engine 4 Tutorials”?




L. Spiro