Right-clicking tickers causes absolute chaos! Maybe should make large steps instead?

[m-7761]

FYI: Single incrimenting the +/- clickers is not super practical. Users might try to see what right-clicking does. In that case mysteriously multiple values change by large quantities in seemingly random ways!

The UI is pretty spartan. I feel it'd be worthwhile to at least make right-clicks increment 5 at a time or something. I think the color filter in many cases can make due with going by the Blue channel by itself. My room is okay lit. With the default settings everything is very dark. The PSVR lights at their brightest are more white than blue, but are super bright either way...

It's pretty obvious what's what. By just testing the blue channel, the algorithm would be much simpler, and so more likely to perform well on systems with starved CPUs... as a baseline solution. This is kind of off-topic, but I feel like selecting appropriate colors is way too complex, even from a setup perspective. The system has to be much more stupid than that by default. I mean, if an AI visual system can't see stark blue/white on stark black, it's not good for a whole lot! End-users can't be hassled to micro-manage settings. It really should just work.

[HipsterSloth]

Yeah, the color calibration tool is pretty miserable to use at the moment. It's a port of the tool I used for calibrating the PSMove controllers, which is why it's more general purpose with the color filtering. The right click actually samples the pixel at the click location and used that guess at what the HSV filter values should be:

https://github.com/HipsterSloth/PSVRTracker/blob/master/src/psvrconfigtool/AppStage_ColorCalibration.cpp#L525-L562

This isn't documented anywhere in the UI (Super helpful I know). Anyway, the intent is that right-click is a starting point, and then you only need minor adjustment. Totally agree on supporting a larger step size though.

You are right it should be more a automatic process. Like everything else with the project it's just something I haven't had a chance to implement yet. I started with the manual calibration because previous automatic color calibration algorithms I've used in PSMoveAPI didn't work half the time and I wanted manual control. Definitely not something that should be the mainline case though to be sure.

I don't know if just filtering on the blue channel would work in all cases. Different cameras and different lighting conditions cause surprising variations in hue. That's said, I haven't tested that, and that definitely seems like an experiment worth trying.

[m-7761]

I think using blue (shifting the 32-bit pixel) is a good default starting point. If it doesn't just-work then users can think about changing their lighting/setting/etc. or dig into more advanced settings (and consider the trade-off on the CPU. E.g. Is it worth not flipping off your light switch?) Doing hue-calculation on pixels is a very costly computation.

I have MSAA code for masking alpha-tests for cutting things out in games that would probably be a better fit for the triangular DS4 light-bar if worthwhile. It can figure out the angles with minimal computation just as anti-aliasing works by figuring out angles. If this can work at all, the best approach is going to be starting out with the dumbest possible algorithm, because that can actually be computed in real-time, reasonably, and it's criminal to use more cycles than necessary.

We have to look at the problem like a fighter-jet locking onto a target. We can't have perfect knowledge, we just have reasonable knowledge, the better the lock, the happier the end-user. The visual problem is just a grounding function. We have the sensors in the IMU that are much better (and give reasonable states for the locations just by themselves.)

In theory I think it should be very simple. You just have to take two closet lights, figure out what pair they can possibly be, and test the rigid body against those pairs. Any more lights can validate the test. Having two cameras (at two different locations) would help to see more lights at once. Distance between the lights is a reasonable guess on distance from the camera, as is their size. An algorithm just needs to fudge these things. I'm good at developing this kind of algorithm if I can just get everything working. Right now I feel like my days prodding this code-base aren't being productive. But it's understandable. Problem solving doesn't always go swimmingly. Bottom-line is a solution that can't run on a CPU is not useful, and neither is one that doesn't allow games to use as much as the CPU as possible. (Running the cameras on another computer is another option for people who really can't spare the CPU cycles.)

[m-7761]

Hey! Just to share in a semi-public space... on the topic of the UI... i'm shifting gears to work on a UI that maybe can be used in the absence of PSVRToolbox: https://sourceforge.net/projects/widgets-95/

I'm starting work on this more or less immediately. I want to keep trying to get the USB/HID stuff online. But if you want to take a break for a little while, I'm fine. I don't know what PSMoveService has in the way of a UI, but I think this project will be interesting. It's welcome to use it and inform its design if need be. I'm going to use it first to replace GLUT in the COLLADA-DOM reference-implementation of COLLADA that I now maintain. That will be its first application, including a location-bar for inputting URLs and clipboard support.

It's going to look like Windows 95 by default. But it's going to have a VR mode assuming I can make it work with OpenGL. Direct3D 9 has multi-stream vertex buffers, which is how I implement VR with it. I assume OpenGL has an equivalent functionality, but I'm uncertain.

EDITED: Here (http://www.cs.unc.edu/~rademach/glui/) is some pictures of GLUI for reference. I kind of like the throwback look myself. The use of 95 is tongue-in-cheek nod to when VR was popularized on television in the 90s. It's like an alternative universe UI. I think the stark bevels will look good in 3D. (I'm going to redesign that rollout widget. It's like a collapsible group-box. Otherwise everything looks pretty cool to me.)

EDITED: That links says license is LGPL but the current license on GitHub is Zlib's permissive license. That's an old website.