Skip to main content

Polishing Snapping and Spawning Objects

Finishing the alpha prototype made up the majority of the work completed this week (~20 hours), but even after the alpha presentation there was still some more work and polishing to do with snapping components together (~4 hours), and then work began on dynamically spawning modular furniture (~2 hours) pieces and that will be the focus of this coming week.

Creating the snapping functionality we desired for our alpha prototype proved to be quite the challenge, and this was not because of the logic or technical requirements behind snapping objects, but rather due to some limitations of the A-Frame Physics System library.  Before going into these limitations I will go over the two approaches taken to try and create this functionality.  
The original approach was to take the smaller piece that was attached parent it to the larger object, and then apply translations to the piece to line it up correctly.  However, in practice sometimes the transformations would not apply to the component and it would remain positioned the same way it was originally attached, and the rest of the time A-Frame itself would crash, which is not ideal.
The second approach was to clone the object being attached, use the clone as the attachment, and delete the original part.  In practice, the clone was not a full clone and did not partake in the physics system, so was not solid, and trying to delete the original component in any fashion caused A-Frame to crash. 

An inordinate amount of time was spent trying to interpret the error and warnings messages thrown by A-Frame the Physics library and Three.js, but eventually, through much trial and error, I was able to determine the crashes occurred were because the physics system does not now how to handle dynamic objects that are removed while undergoing collisions, and transformations were not applying to attached parts because the physics system would override the new values.  In the end, the prototype used the cloning method and the old part was just hidden.  The current build uses the first method, but there is still some fine tuning to do.

I tried to record an example of the alpha prototype in action, but for some reason my screen capture software cannot record a browser window that has the mouse captured.  Instead here is an image of the partially completed table. 

How the game appeared for the alpha.

The snapping functionality should be the biggest technical hurdle, so with luck the rest will be smoother sailing, but we all now that is not how software development works.

Comments

Popular posts from this blog

[WEEK 1] Introducing our project...

Our goal is to make a cool VR game for Design Studio 3. The main idea involves a collaborative asymmetrical experience to build furniture virtually. There will be two roles in this game: a finder (to look for furniture pieces in the warehouse), and a builder (putting the parts together). We started this project on January 22, 2020 and are currently on our first 1 week sprint of development.

Sprint 10 - Adding more boxes and lots of scripting

As the final submission draws near, lots of work has yet to be done. Due to time constraints and the lack of resources in light of recent events, we made the decision to cut down our scope by removing VR functionality entirely and focus on desktop-to-desktop connection fully. With new goals in mind, I spent the beginning of the week by adding all the boxes for spawning furniture components. To do so, I started by replacing the blue boxes we used previously with stylised boxes that match the environment better. To tell the player what each box contains, an image of the rendered component is placed on each side. The challenge here was that I wanted to avoid creating a GLTF for every single box because it would have slowed down the page drastically. The solution was to instead use a single, universal GLTF for every box and placed images on each side of the box as explained previously (~6hrs). New Warehouse Area - Added new boxes Close up of updated box - Bright colours and side

Storyboard and Physical Layout

I finished up on some graphical elements for the user interaction specification component of the proposal due this coming Friday. This includes the storyboard panels and the physical layout diagram. As I was researching Oculus Rift physical setups, I had to determine how many sensors we would need for our game. I believe that 2 sensors will be sufficient, since we do not need a true 360 degrees experience as the Builder player will primarily be focused on the 180 degree space in front of them (i.e. the fireplace, the TV, and building the furniture). Our game is not an action packed game with any running or shooting. Of course, the player will still be able to fully look around but they shouldn't have a great need to move in the other 180 degrees of space. This would also take into consideration accessibility to our game, because it costs extra to buy a third sensor (the Rift only comes with 2) as well as requiring adapters and wire extensions. I spent about 4 hours researching