PlayStation Move technology thread

Technical limitations, perhaps? I recall Marks stating that tracking with the Eye Toy on PS2 could consume upwards of 30% of the CPU resources. Perhaps the IR emitter bar plus IR sensors in the remote allows for reduced overhead? Less data to filter maybe?
I considered that, bit, if nintendo are to be believed, they selected their hardware to drive the games they wanted to make. If they wanted a Move-quality interface, they could have put better hardware in Wii to support that. I don't believe they said, "we'll patch two GCs together to make our next console, and then see what we can do with that regards novel interfaces."

I suppose as shadowrunner says, the gyro's weren't viable at launch, which would limit rotational input. That wouldn't be possible with a sphere, whereas it is possible with the dual light sources, if not terribly accurate given lateral motion. If the intention was pointing at the screen, I can't think of any alternatives in the time-frame either. That said, they new they were going to add Motion+ eventually once the price came down. It must have been a hard compromise to make...hey, who am I trying to kid?! How much money have Nintendo made?! Who cares if it's afar from ideal tech when it churns out this many dollars!!
 
Yeah, from Nintendo's perspective, if they could implement fun games on top of the tech, it's probably good enough for other titles. The developers can usually work around the hardware limitations by designing the game differently. What's important at that point was the cost/price. Nintendo probably needed extra $$$ for marketing Wii to the world.

In contrast, since Sony doesn't talk about the final user experience, most of our discussions center around better (and better) tech specs, plus the occasional "ideas" posts.

I wonder how much of Sony's advanced tech will get used for real. If the devs go for Wii + PS3 games, they may create an experience that works equally for both, then slap some PSEye gimmicks to make Sony happy.

At some point, Digital Foundry should do an article on the implementation approaches for complex motion tracking. There seems to be multiple way to slice and dice the tech. Also is consistent 1-1 tracking really better than WiiSports Resort's gyro only tracking ? Is absolute positioning only useful in direct manipulation of in-game (3D) objects ?
 

Sat down to watch the demoes I missed last week. The new elements (Chameleon, Lego, RTS selection, dummy manipulation) are more or less the same as earlier demoes, but more refined/stable (less shakey cam). They are still a little too abstract.

Would :love: to see these building blocks combined/layered with other elements:

* Motion combos
e.g., (While I ride on horse back), swing a lasso overhead, throw it around a cattle's neck, topple it and tie its legs together, all in one smooth sequence. Chimpanzee/Tarzan swinging from branch to branch, somersault, and climb up and down trees -- think Mirror's Edge; Indian chef flipping Roti Prata using 2 motion controllers as the pancake expands, etc. These would convince me that the Sorcery demo is not a "one-off" trick.

* Online + motion
Cooperating to build complex Lego structures, holding hands with online players, in general working with other players with more precision (e.g., threading needle)

* Interactive content + motion
The earlier "Minority Report" demo showed video playback as Anton twist the window. Should allow us to interact with the content in the warped layer directly. Now it's just a static image or empty background. Would also be nice to see a 3D structure crumble (with proper physics) as Anton select a map section using the RTS painting method, and then twist the selected areas using the warped window method.
 
patsu said:
at some point, Digital Foundry should do an article on the implementation approaches for complex motion tracking. There seems to be multiple way to slice and dice the tech. Also is consistent 1-1 tracking really better than WiiSports Resort's gyro only tracking ? Is absolute positioning only useful in direct manipulation of in-game (3D) objects ?

I'm writing something like that as a hobby project, we'll see where that ends up. But you should search for wii table tennis ps3 move on youtube and watch that first video. It shows why absolute tracking in space can matter a lot.
 
I just saw the YouTube video in question. In practice, the WiiSports Resort gaming experience is not as bad as the video highlighted. This is mainly because the AI is pretty smart/responsive. Secondly, the resort/vacation mood in the game makes every activity seems fun and relaxing.

The hardcore mode in Sports Championship may provide more realistic action. But if the enemy AI is tuned "wrongly", the game may become dry and difficult -- since there is nothing else in this "level" besides pure ping pong. Earlier impressions also mentioned that Sports Championship was more laggy, probably because it needs to track more variables. I certainly hope that the developers can overcome these issues and deliver a fun experience.

EDIT: I'm aware Sports Championship supports multiple difficulty/mode. It may mean they need more play testing to guarantee a smooth transition between modes.
 
http://www.pushsquare.com/17154/sports-champions-on-playstation-3-hands-on-impressions/

Admittedly, Sports Champions has about as much charm as a limp sock. But having got hands-on time with the compilation’s table tennis game, we’re not sure it matters. That’s because PlayStation Move works; this is not a device playing on empty promises and faked lifestyle commercials – it does what Sony have always said it will: track your movements 1:1.

The author seems to like it.

The first thing we tested was just how well the PlayStation Move could track our paddle. The game adopts a first-person viewpoint when you’re serving or rallying, so the only thing you’ll see in your area of the screen is the bat you’ll use to hit the ball. It’s almost startling how well the PlayStation Move is able to track movements. We twisted, lunged and waved our arms around; every action was perfectly mapped to the screen without any distinguishable lag.

That accuracy transcends into the gameplay. Playing the game feels like real table tennis. ...
 
I was afraid they simply shove Move support into XMB like this.

For usability, I think it's better to make the XMB main icons static and let the user target the stationary icons by pointing and clicking. If they let the horizontal icon scrolls, the user will find it hard to target the icons properly (too "slippery"). They should give us an option to lock the the horizontal scrolling for Move. Unfortunately, the icons may be too small for fast targeting, so they may have to increase the icon size or target area as well.

The 2-dimension Photo icon layout is also more suitable for Move as opposed to the 1-dimenion icon list. Fortunately the PS Store layout is more Move friendly compared to XMB. The static icon layout in PS Store will also make transition between a static icon XMB and PS Store seamless.



For the out-of-control Chick demo, I suspect it's because the user did not hold down the trigger to activate the fan.
 
It also has some of the first time I've ever seen some technical issues...
oo, yeah. Right at the end, the fan overlay is placed way off to the bottom left. The Move tracking seems to see something down there that it takes to be the sphere, although with the game graphics overlayed we can't see what. I suppose this shows the system isn't tracking based on human physiology, which could help solve that. In the tracking, it should look for Move's current position near to where it last was, within 1/60th of a second displacement attainable from a fast swing.
 
This begs the question, why did Nintendo go the route they did? I wonder if Sony holds patents on using tracking props, made in the EyeToy research days, that prevents a console-centred visual tracking, forcing Nintendo to place theirs in the Wiimote? It was it more a lack of tracking tech and research into sphere tracking that left Nintendo with an uncertain method, resulting in reliance on triangulation of two points and the controller, which would lead naturally to the current Wii solution?
Cost? They wanted to support local multiplayer and spend as little money as possible. The Wii couldn't use color-coded light to discern players. It uses the cheapest possible beacon light sources and the cheapest possible camera technology (both monochrome IR). With a detection scheme like this, you can't reverse the setup as Move did. Multiple controllers in front of the camera couldn't be distinguished.

Putting the sensor into the controller also moves the bulk of even that expense back to the consumers, because they have to pay extra for each controller they purchase.
 
oo, yeah. Right at the end, the fan overlay is placed way off to the bottom left. The Move tracking seems to see something down there that it takes to be the sphere, although with the game graphics overlayed we can't see what. I suppose this shows the system isn't tracking based on human physiology, which could help solve that. In the tracking, it should look for Move's current position near to where it last was, within 1/60th of a second displacement attainable from a fast swing.

I think it might be the rotating colour floor lighting which is activated for the second part of the demo?

I assume that once the system decides the floor lighting is the controller, it continues to track the changing floor-light shade (in case the real room lighting changed) - which makes it harder to detect the controller when it leaves that block of colour.

Constraining a system makes it very easy for the controller to 'stick' (a bad reading pushes your system into a state where valid readings are considered impossible - similar to what might have happened above). For kinect & Move at each frame you can resync your 'model of the world' with your reading of the world - having constraints is not necessarily helpful.
 
What is the frame time for the scene in question ?

EDIT: Found it ! 6:58. I didn't see the bottom left fan initially. ^_^
That is a strange error. Was the light ball on when the fan "disappeared" ?
 
What is the frame time for the scene in question ?

EDIT: Found it ! 6:58. I didn't see the bottom left fan initially. ^_^
That is a strange error. Was the light ball on when the fan "disappeared" ?

Yes - if you watch the floor in the corner, you'll notice it turns purple (the colour of the ball) every time it happens:
- at 6:58 it turns purple and goes wrong.
- the problem repeats at 7:27 when the floor once again is purple
- it also repeats when the next player is on (7:40) and the floor is purple.
- it repeats again around 8:20 when the floor turns purple again.

It looks like a pretty stupid place to demo it!
 
Constraining a system makes it very easy for the controller to 'stick' (a bad reading pushes your system into a state where valid readings are considered impossible - similar to what might have happened above). For kinect & Move at each frame you can resync your 'model of the world' with your reading of the world - having constraints is not necessarily helpful.
I don't understand the problem. Tracking of the sphere is confused by the presence of another similar colour signal, miles away from the area the sphere is at. You can tell from limits in human physiology that the ball will be no more than...30 cms from frame to frame, which will be somewhere within a zone of the screen centered around the current signal. Thus you test for sphere presence in that box. In the above case, the presence of the hot zone in the bottom left would go ignored because it's too far from the current placement. I don't see why such a system could lead to sticking objects where the signal is lost. In the case the sphere isn't found (which would surely just be a poorly sized sampling window), you'd just extend the sampling window, maybe to the full screen. I suppose worst case, you could have the sphere lost, search the whole frame, and find a wrong signal. But that's no worse than we have here with the fan sticking to a false signal, while also this situation shouldn't arise.
 
Yeah, seems like a bug to me. Should be able to reduce the effect by adding a stricter exit condition for light ball detection. Once the system notices more than one purple light sources in the frame (instead of locking on to the wrong light source), it would also start to change the light ball color automatically like in the usual case.
 
I don't understand the problem. Tracking of the sphere is confused by the presence of another similar colour signal, miles away from the area the sphere is at. You can tell from limits in human physiology that the ball will be no more than...30 cms from frame to frame, which will be somewhere within a zone of the screen centered around the current signal. Thus you test for sphere presence in that box. In the above case, the presence of the hot zone in the bottom left would go ignored because it's too far from the current placement. I don't see why such a system could lead to sticking objects where the signal is lost. In the case the sphere isn't found (which would surely just be a poorly sized sampling window), you'd just extend the sampling window, maybe to the full screen. I suppose worst case, you could have the sphere lost, search the whole frame, and find a wrong signal. But that's no worse than we have here with the fan sticking to a false signal, while also this situation shouldn't arise.

My understanding specifically of Move:

- the failure is outside the scope of Move. (Move relies on the ball being a unique colour within the scene - that was the original reason given for the changing colour, so this "failure" is unlikely to keep the developers up at night). The only obvious problem for move is whether a reflection of the controller on a shiny surface would confuse the system (I suspect it might - although I guess that's not a very common occurance).

- in all likelihood move picks either the 'best' matching signal, or the 'first' matching signal. The requirement is to be able to carry out all the processing within the resource limits given to developers - e.g. miniscule lag/memory/99% predictable cpu usage, being able to handle stupid lighting arrangements isn't worth sacrificing system performance.

[I would expect this to be labelled 'wontfix'/pebkac]

The "constraint" in the movie appeared to be colour-based:
- at t=0 the best matching colour is purple, and it picked the wrong purple even if it was searching based on the last position - mistakes can happen.
- at t=1 the best matching colour is purple+1, so for the next frame it's looking for the colour purple+1. (the lighting etc may have changed)
- at t=2, the best matching colour is purple+2, so for the next frame it's looking for the colour purple+2.
- at t=255, the coloured light switches to red, but the system is still looking for a purple 255... (the actual Move controller led probably doesn't match this colour, leading to a system that doesn't know whether the led is obscured or the system is stuck).

[the patent below seems to say that this is how it works - and it can be broken in precisely the manner shown in that video]

---

Probably worth adding these 2:
Someone got hold of a move controller and opened it. The innards are spectacularly boring - the ALPS chip I'm guessing is an input controller-thing, it looks like an ARM chip in there too, and the rumble bit is clearly seen:

http://www.examiner.com/examiner/x-...ion-Move-controller-dissected-Images-and-more

And a patent that is 'mostly the Move' and probably should be included somewhere:
http://www.google.com/patents?id=cZjRAAAAEBAJ
 
It's quite an extreme example that causes the issues though, isn't it? A background that continuously chances color in various intensities. Probably changes just too fast for it to ask for auto-recalibration, which it can't do too fast as it doesn't matter so much if you quickly move the controller over a lamp or a reflecting background or whatever. Otherwise I've seen that it would normally pauze the game, show an 'auto-recalibraion' message, pick a different color and allow you to continue. But in this case it wouldn't have helped solve the problem as the background basically cycles through almost all colors and intensities all the time. I can't think of very many other things that could even theoretically confuse this thing ... :D

I was afraid they simply shove Move support into XMB like this.

Did you take enough time to look at it to see how fast it works though? You should try selecting something with the controller. I think with the Move you can select something amazingly fast, I'm actually very impressed with it. I hope that while it may not be the flashiest thing ever, that at least some people see how elegant it is to have a user interface that can so easily be used with mouse, keyboard, d-pad, analog stick or now the Move controller.
 
You should try selecting something with the controller. I think with the Move you can select something amazingly fast, I'm actually very impressed with it. I hope that while it may not be the flashiest thing ever, that at least some people see how elegant it is to have a user interface that can so easily be used with mouse, keyboard, d-pad, analog stick or now the Move controller.

Seemed to scroll vertically and horizontally much faster than a DS3/BT keyboard to me so it will definitely be serviceable. I was hoping that a tailored interface would launch with it though.
 
Did you take enough time to look at it to see how fast it works though? You should try selecting something with the controller. I think with the Move you can select something amazingly fast, I'm actually very impressed with it. I hope that while it may not be the flashiest thing ever, that at least some people see how elegant it is to have a user interface that can so easily be used with mouse, keyboard, d-pad, analog stick or now the Move controller.

Yes, the speed also means that it can be easy to make mistake quickly. If you try to use XMB with a trackpad/mouse, you'll see what I mean. The scrolling can be "too slippery".
 
Back
Top