I am having a issue where i suppose to load a large number of objects in my scene on an event,
so when ever i start loading these Scenesmy Vive/vr goes to compositor screen and it kinda flickers between my main scene and compositor screen
until my loading of Scenes is finished.
So my question is how to stop this flickering, i am happy to call the compositor screen till my Loading is completed and then it switch back to my Main scene or something like that which can solve this flickering issue
i have been searching around that how to call compositor screen on my own or how to stop it being called when my Loading is in progress but in vein.
any help would be much appreciated because i am out of ideas.
Thanks...
Flickering and showing compositor screen is generally caused by Unity not being able to Render a frame. I'm sure you will be able to find which object(s) (if any in particular) is causing a lag in the Profiler Tab.
I assume by "Loading" objects you mean Instancing them. If so, it depends:
a) If you instancing multiple identical objects - look up into GPU instancing methods
b) if the objects aren't unique, you may try to:
Load scene asynchronously
Place all (deactivated) objects on the first scene and instead of instancing or
loading new scene, just activate them. This will only increase initial loading
time.
Another things that you can use is:
Single Pass Stereo Rendering
use of ONLY or mostly baked lightning - which will SIGNIFICANTLY increase performance (that let me display in real time VR scene with model that counts more than 40 million vertices)
By default, SteamVR fades to grid whenever an app hangs. While of course it's ideal to keep your framerate above the threshold that would normally trigger this, there are many cases (such as loading scenes) where all the optimization in the world won't keep Unity from hanging long enough to trigger this issue.
Fortunately, this behavior can be disabled entirely! SteamVR Settings -> Developer -> Do not fade to grid when app hangs. This setting can be also be changed in the steamvr.vrsettings file which can be found using vrpathreg.exe. There, set steamvr.doNotFadeToGrid to true. This file is modified by the SteamVR Settings interface as well, but accessing it via the file directly allows you to modify settings for your target devices from within a game installer, for example.
Unfortunately as of now there isn't a way to configure this on a per-app basis, meaning the behavior will be turned off for all SteamVR apps on a user's machine. Tweaking this setting comes with the caveat that low framerates make users feel sick and the fade-to-grid feature prevents this from happening. However, in my experience, the feature is a nuisance that detracts from immersion far more than a temporary dip in framerate as long as you're following performance best practices, and if framerate is dropping anyway, this fade to grid feature causes intense flickering that's just as uncomfortable as low framerate.
Related
I have a heatmap plugin integrated in my Unity VR game(with SteamVR). The plugin uses eye tracking information to generate live heatmaps as the user gazes at different elements in the game. As the heatmaps are generated, the whole camera view(user's) is overlayed with heatmaps info and written to a MP4 file using FFMPEG.
The whole process works fine. But I have an annoying problem where during the recording the user's camera view is not stable and keeps flickering and stops only when the recording is stopped. It interrupts the smooth flow of his game
For now, I've narrowed down the code which causes the trouble,
public void Write(byte[] data)
{
if (_subprocess == null) return;
_stdin.Write(data);
_stdin.Flush();
}
From my understanding, It is in this part of the code stdinput is invoked to write to the file system. So, I surmise that the problem must be with accessing the file system which in turn must have caused some time delay when each frame is written in the update method. Correct me if i am wrong here.
The loading screen which appears during every frame write looks something like above. It interrupts the smooth flow of the game and also makes the recording useless as the user keeps focusing on the flicker rather than the actual objects of interest. I would really be grateful if someone shows light on the issue here?
Accessing the file system always takes a huge amount of time. Try offloading that work to another thread or a Coroutine.
I'm using a Wiimote controller as an input device.
I'm using this wrapper for HID calls / polling.
In the demo scene that comes with this wrapper, polling the controller is done in the Update event.
In many Wii games aiming extremely up and down quickly triggers an action.
The wrapper indicates extreme vertical aiming positions (where the aim goes out of scope / is "offscreen") as
Y=-1
I tried to detect such a rapid up-down movements by
1) Detecting if aim is off-screen
2) If yes, have a look if the aim is within the screen again
3) Detect if aim is off-screen again and if all this happened in a certain time period
The problem however is (I think due to the nature of polling only in the Update event), #2) doesn't necessarily have to occur. It's possible that the aim was in the screen, but the controller wasn't polled when it was.
I would like to ask what might be a valid solution to this problem.
Your polling would have to be pretty bad for this to be an issue, but other than increasing the poll rate, there isn't really anything you can do here.
The only other option would be to use the gyroscope or accelerometer instead (sorry, didn't bother to check if your wrapper exposes those). You could essentially combine a harsh vertical shake with the point being off screen, but if your polling is an issue in the original solution, it will still probably be an issue here too.
I have a DirectShow graph which records and displays a video source. When I move Video Renderer window to other monitor, what I recorded gets deleted and recording starts again. I searched and found this link which says changing monitor stops and starts the graph. How can I stop the graph from being restarted? I don't want to lose my recording while switching between monitors.
Thanks
The behavior you are describing is basically behavior by design (even though the side effect is pretty much annoying and confusing). Moving a video renderer between the monitors makes it re-allocate hardware resources used to present video, and this in turn needs a state transition. For recording, state transition means opening and closing the file.
Your solution is to either split into presentation and recording graphs, or to use custom allocator/presenter to take care of presentation yourself the way you want. Supposedly, graph splitting (what Wimmel suggests in another answer) is the preferable way adding other degrees of freedom in particular.
There is probably a good reason that the EC_DISPLAY_CHANGED Message behaves that way, so I don't know what the disadvantages are when you handle this message yourself and don't restart the graph.
Instead you could separate the rendering graph from the recording using GMFBridge. Use one graph to capture and record. Use the second graph only for rendering, so restarting that graph would not stop the recording.
Edit: Possibly you need to disconnect before the second graph is restarted. That will mean you do need to process the EC_DISPLAY_CHANGED message, even if you use GMFBridge.
m_pController->BridgeGraphs(NULL, NULL);
I'm trying to come up with a general concept for transitions, without having to include any specific code inside the actual scene. In all the samples I've seen so far the scenes handle that stuff themselves. Like a fade in/out, where the scenes have to adjust their draw method, for the correct transparency. But not only would this be annoying to have in every scene, with multiple kinds of transitions you'd get cluttered code pretty fast.
So I've been thinking. The only way I could come up with to support this, and more complicated transitions, without handling it in the scene itself, are render targets for each scene. The render target would be set from the scene manager before calling the draw method. After draw the render target would get reset to the render target of the manager, and the scene's texture would get drawn with information about the current transition. Without clearing the manager texture more scenes would follow, if more have to be drawn. This way you could do pretty much anything (transition wise), the scenes would be completely independent of each other, and you wouldn't need a single line of transition code in the actual scenes. (For reference, there are various transition types I'd like to be able to do. Not only fades, but also shader effects, moving one scene in while the current one is "pushed away", etc., involving one or multiple scenes.)
Well, that's my theory. Here comes my question: Does this sound like a viable plan? Is this the way to go? I've read about performance problems when switching rendering targets too frequently, and other problems, which is the main reason I'm hesitating to implement this. But so far I couldn't think of or find a better method. Although I think it shouldn't make a difference, for the moment I only care about 2D (mentioned just in case).
That, in general is a sound approach, but beware render target switching costs. Also, if each scene were to be animated at the time of transition, you'd be rendering two scenes at the same time into two different rendertargets and then compositing the results on screen.
I developing a simple 3D model viewer on XNA 4.0. Is there a way to avoid a infinite game loop with Draw and Update functions? I need render 3D graphics, but without infinite rendering of scene. I mean I need redraw the scene only then it really changed.
I suggest taking a look at how they're doing it in their samples:
App Hub - WinForms Series 1
App Hub - WinForms Series 2
Why exactly do you want this?
If you use a winforms application you have more control on your update and draw loop, but you also could render the scene to a texture first, and then stop rendering at all.
You are going to have to roll your own multi-threaded loop; if you stall either Update or Draw the other will get stalled too. Another consideration is that if your window gets obscured somehow (under non-DWM environments; a window overlapping it for instance) stalling the Draw will leave areas of your window unpainted.
If you want to go ahead with this; what you will do is start a Thread the first time Update gets called and subsequently use a ManualResetEvent to synchronise the two.
A far more robust option is to render your entire scene to a RenderTarget2D when the scene is updated; if the scene has not been altered since the last Update or Draw call simply render the RenderTarget2D instead of the whole scene. This is still an infinite loop, but it tends toward your requirement (even though it does not meet it).
This sort of scenario would be best solved by using WinForms or WPF as the host for your rendering system. I have worked with such systems before and I found using SlimDX with WPF Interop was my preferred solution. Using this approach allows for the addition of nice UI features provided by WPF, overlain on a 3D model rendered to a surface.