Chess, Pencil Art, Piano, Composing, Playing Games, Programming Games, Acting on Japanese TV/Movies, Authoring, Designing Games, Martial Arts, LEGO® Technic™, 3D Modeling, Japan, Tokyo, ภาษาไทย, 日本語, le français
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.
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”.
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.