Disneyland Resort

[Jake S]

Again, tail wagging the dog here on the complexity of a technological solution that wasn't needed, doesn't improve the scene, and in many cases actively harms it.

Yep. They're not looking for tech solutions to tell their story. They're looking for story solutions to use their tech.

 

[Freak]

Also, why the hell are they feeding the data back into Unreal Engine? Just so they can have the projection on the animatronic update without actually having to redo the animation? So instead of just having a video play on a projector on a pre-canned animatronic animation, you're having an Unreal engine scene render this animation in real time?

Again, tail wagging the dog here on the complexity of a technological solution that wasn't needed, doesn't improve the scene, and in many cases actively harms it.

Is there an actual reason they need to use Unreal Engine to store the video data on? Is there a reason why they can’t just use a “canned” data base to do that on?

I don’t hate this addition in isolation. Pacing and story concerns, sure. There are so many worse things Disney could’ve done with this ride.

 

[PerceptiveCoot]

Yep. They're not looking for tech solutions to tell their story. They're looking for story solutions to use their tech.

And it doesn't help that the people selling it are these awkward breathless nerds speaking a mile a minute who don't know how to pace their speech.

It's odd, a lot of the recent content on the Disney Parks marketing channels has been much more relatable and down to Earth, often focusing on operations and engineering working together to bring an attraction to life during the final hours of its' development. In those videos, everybody is talking and interacting with each other normally. Nobody is prattling through talking points rapidly as if they're afraid that slowing down will be less convincing.

Is there an actual reason they need to use Unreal Engine to store the video data on? Is there a reason why they can’t just use a “canned” data base to do that on?

Per the video, if a motor is not working on the animatronic, they want the lighting and animation on the face to still be accurate to the animatronics current face position. Thus, they likely need to render the animation in real-time to account for the multiple positions the animatronic will be in....

That's their argument, but I don't find it convincing, as the range of motion on this animatronic suggests that its face likely won't be moving outside of a highly specific range? Unless they've completely failed to support the animatronics head.

In my opinion, rendering the animation in real-time is more about "flexibility" (i.e the inability to commit to decisions in the preproduction phase, or the desire to do so to allow for more excessive micromanaging and tinkering by executives as the project goes along.)

 

[Parkscope Joe]

Is there an actual reason they need to use Unreal Engine to store the video data on? Is there a reason why they can’t just use a “canned” data base to do that on?

I don’t hate this addition in isolation. Pacing and story concerns, sure. There are so many worse things Disney could’ve done with this ride.

The face is rendered in real time based on the location of the figure. This is less a video and more a video game character, if you get my drift.

 

[Cwoolboy]

I wouldn't say this ruins Pirates in any degree. That said, it doesn't fit the area it's in and just doesn't look all that good in general. Saying it's "Next-Gen" is definitely quite a leap, especially when you can see the same exact tech elsewhere. WDI didn't break any barriers here.

 

[Mr_Pendington]

Here is the video, I'm mixed. I think its both cool but also....like somewhat ruins the tone of the area

I think for sure this is going to be very hit or miss for most. Maybe just tone down how cartoon it feels with the sound effects and everything to help

Animatronic only for those with little time. Im very happy to be proven wrong about its reliability (I'd rather be), this is a good use of that effect all things considered. Although looping it infinitely really does break that cohesion

 

[PerceptiveCoot]

Saying it's "Next-Gen" is definitely quite a leap, especially when you can see the same exact tech elsewhere

Even if it's next generation, I think people are generally hostile toward the projection faces. As advanced as the projection may be, it's never going to beat a real physical face for some people. Perhaps they internally see a non-moving animatronic with an animated projected face as a more ideal failure state than a non-moving animatronic with a physical motionless face, but I bet if I queried riders, it would be obvious which one they preferred.

Again, irrespective of whether the tech works, I don't think it belongs in this ride and it especially doesn't belong in this scene.

Now, deploying this technology in something like the Coco ride would make more sense, because

A. There's no pre-built decades long expectation of what the pacing and tone of each scene should be.

B. The projection technology would allow you to properly display the cavities and abscesses within the skeleton's face.

C. You can create a high quantity of physical animatronics with projected faces at a cheaper cost than you would be able to if each of the dozens of animatronics had intricate facial architectures. So instead of building 6 skeleton animatronics in a scene, you can now build 25, because your costs only extend to the simpler motor components of each animatronics respective bodies. You would essentially use the projection as a budgetary cheat to increase the vibrancy of the side characters in your scene, while your main characters (Hector and Miguel) remain traditional animatronics.