Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Software Engineer’s Guide to Unity and AR/VR Development – Part 1

blog.betawave.io

Post reply on HN
Print view View original

11–20 of 36 posts

Re: A Software Engineer’s Guide to Unity and AR/VR Development – Part 1

#11

Post by ryandrake »

andybak wrote: post #2

I've recently started exploring the world of Unity and the weirdest thing about it is that it's 90%/10% in favour of video tutorials - even for the purely code-based aspects. Even Unity's own official tutorials are all in video form.

I'm seeing this more and more for other things, programming and non-programming, like "How to do XYZ with a Raspberry Pi". I'll generally try to skip the videos because they are almost always awful in terms of time efficiency. Instead of what should be a single page of text with 8 written steps, we now have all these 5 minute videos that start with a 20 second spinning logo intro, then a blank desktop and someone saying "Hey guys, today I'm going to..." It's halfway into the video by the time he's even gotten the subject matter on the screen. Then at the end there's a 30 second outtro with "Hey, guys, if you liked this tutorial, go ahead and like, subscribe and comment below! And check out my Youtube channel and like and subscribe! And if you didn't like this tutorial, go ahead and like and subscribe anyway! Catch my other great videos on my channel and of course like and subscribe!!"

Re: A Software Engineer’s Guide to Unity and AR/VR Development – Part 1

#12

Post by RangerScience »

VTRK (https://github.com/thestonefox/VRTK) will almost certainly make your life better. It's (well done) implementations of (most? all?) the core AR/VR interaction patterns that have been worked out so far.

I might go so far as to say it's the ActiveRecord to Unity-as-Rails for AR/VR, although the analogy is really flawed.

While I like your overall approach (a true, comprehensive intro to Unity), I would have liked to see more about, I guess I'd call it, the philosophy of putting code into Unity, covering (specifically and, IMHO, most importantly) the type of component system they're using, and type of event system they're using. The equivalent of describing a new language in terms of which features from the language grab-bag the authors decided to use.

PS - Pluuuuug, because dealing with JSON/YAML in C# suuuuucked: https://github.com/narfanator/maptionary

Re: A Software Engineer’s Guide to Unity and AR/VR Development – Part 1

#13

Post by andybak »

TheGRS wrote: post #10
munchbunny wrote: post #7

Earlier quoted context omitted.

It's likely the highest ROI way to package it, relative to active effort, i.e. excluding time waiting for video encoding. You record a few minutes, narrate over it, and post it.

This is where I've found Lynda's tutorials great. They align the text to the video so you can see and read at the same time. I was able to get pretty far by reading Unity In Action though, which was purely just a book tutorial and I really enjoyed it. So I don't know, I would attribute it more to a younger audience who is more receptive of videos over written tutorials.

> I would attribute it more to a younger audience who is more receptive of videos over written tutorials.

Is this really true? There's some inherent advantages to words and pictures vs video and audio that can't be hand-waved away as 'preferences' or 'learning styles'. Has an entire demographic really chosen a medium that nullifies such powerful techniques as skimming, copy/paste, seeking without laborious workarounds, variable speed of consumption etc.

Re: A Software Engineer’s Guide to Unity and AR/VR Development – Part 1

#14

Post by Impossible »

I hate to be that guy on HN but this article set me off as a Unity VR developer. I understand this is an introduction for people coming from a web development or other more traditional software engineering background, and the code is purely demonstrative, but it's full of Unity performance anti-patterns. Specifically...

1) Resource.Load and GameObject.Instantiate during a runtime loop. Both of these are very expensive and will generate a ton of garbage.

2) Constantly Instantiating and Destroying GameObjects during runtime. This will create a ton of garbage on top of the expense of the Instantiate. The solution to this should be an object pool (http://catlikecoding.com/unity/tutorials/object-pools/ ). Realistically this is probably outside of the scope of this blog post, but maybe the author should have avoided Instantiate in an introductory example.

3) GameObject.Find to locate a fixed game object in the scene. This should be replaced with an object reference (references can be connected in the editor), or if that doesn't work for whatever reason use Find once in Start or Awake and store a reference to the object are a member variable. Unity recommends to not use it every frame in it's documentation (https://docs.unity3d.com/ScriptReference/GameObject.Find.htm...)

4) Debug.Log can be useful in a pinch, but doing it in Update or other frequently called method can cause performance problems, also printf debugging has never been great. Visual Studio debugger support is really good in Unity, use that.

This code is ok if you don't care at all about performance, but in a VR or AR app you can quickly add milliseconds frame time and make yourself sick writing relatively simple code in this style.

Re: A Software Engineer’s Guide to Unity and AR/VR Development – Part 1

#15

Post by amadeusw »

Impossible wrote: post #14

I hate to be that guy on HN but this article set me off as a Unity VR developer. I understand this is an introduction for people coming from a web development or other more traditional software engineering background, and the code is purely demonstrative, but it's full of Unity performance anti-patterns. Specifically... 1) Resource.Load and GameObject.Instantiate during a runtime loop. Both of these are very expensiv…

Are these issues easily fixed by refactoring? As a newcomer to Unity, I'm ok writing poorly performing quick code to experiment, and properly implement the code at a later stage. I'm afraid that I may burn out too quickly if my first interaction with a platform is too much concerned with patterns.

Re: A Software Engineer’s Guide to Unity and AR/VR Development – Part 1

#16

Post by Impossible »

amadeusw wrote: post #15
Impossible wrote: post #14

I hate to be that guy on HN but this article set me off as a Unity VR developer. I understand this is an introduction for people coming from a web development or other more traditional software engineering background, and the code is purely demonstrative, but it's full of Unity performance anti-patterns. Specifically... 1) Resource.Load and GameObject.Instantiate during a runtime loop. Both of these are very expensiv…

Are these issues easily fixed by refactoring? As a newcomer to Unity, I'm ok writing poorly performing quick code to experiment, and properly implement the code at a later stage. I'm afraid that I may burn out too quickly if my first interaction with a platform is too much concerned with patterns.

They are easily fixed with a refactor, but many of the solutions are either easier to implement or not much more difficult to implement than the example code.

Re: A Software Engineer’s Guide to Unity and AR/VR Development – Part 1

#17

Post by zen35 »

Impossible wrote: post #14

I hate to be that guy on HN but this article set me off as a Unity VR developer. I understand this is an introduction for people coming from a web development or other more traditional software engineering background, and the code is purely demonstrative, but it's full of Unity performance anti-patterns. Specifically... 1) Resource.Load and GameObject.Instantiate during a runtime loop. Both of these are very expensiv…

Yup, agreed on all points! You've hit the nail on the head about article scope. We do mobile VR and these are all definitely no-no's at the end of the day. Discussions on perf will come later. Thanks for pointing these out though!

Re: A Software Engineer’s Guide to Unity and AR/VR Development – Part 1

#18

Post by zen35 »

RangerScience wrote: post #12

VTRK ( https://github.com/thestonefox/VRTK ) will almost certainly make your life better. It's (well done) implementations of (most? all?) the core AR/VR interaction patterns that have been worked out so far. I might go so far as to say it's the ActiveRecord to Unity-as-Rails for AR/VR, although the analogy is really flawed. While I like your overall approach (a true, comprehensive intro to Unity), I would have liked…

Yeah, I'm all for more discussions on philosophy instead of just the mechanics of doing X, Y, and Z. Like how does one augment existing physics to capture their game's possibly different/modified/caricatured definition of physics? Can one's games interactions come primarily from emergent behavior or does one need to do more leg work in the game model? Tons of discussion for later, hopefully!

Also: VRTK is awesome and JSON/YAML in C# is indeed terrible.

Re: A Software Engineer’s Guide to Unity and AR/VR Development – Part 1

#19

Post by DoctorMemory »

This looks like a pretty decent tutorial for it's target audience. However, as someone who works with Unity on AR and VR the biggest bit of advice I can give is learn how Unity WANTS you to work with it! Currently we are re-writing an AR/VR test suite because the original version was written by programmers with little or no Unity experience. This means they re-wrote scene loading, cameras, and other parts that were already in Unity (or no one re-factored when it was added/updated!). I highly suggest catching the Udemy Unity Certified Developer course on a sale. It will give you an overview of all the parts of Unity that you might not touch. But it will also get you used to Unity's workflow. (https://www.udemy.com/unitycert/)

Re: A Software Engineer’s Guide to Unity and AR/VR Development – Part 1

#20

Post by RangerScience »

zen35 wrote: post #18
RangerScience wrote: post #12

VTRK ( https://github.com/thestonefox/VRTK ) will almost certainly make your life better. It's (well done) implementations of (most? all?) the core AR/VR interaction patterns that have been worked out so far. I might go so far as to say it's the ActiveRecord to Unity-as-Rails for AR/VR, although the analogy is really flawed. While I like your overall approach (a true, comprehensive intro to Unity), I would have liked…

Yeah, I'm all for more discussions on philosophy instead of just the mechanics of doing X, Y, and Z. Like how does one augment existing physics to capture their game's possibly different/modified/caricatured definition of physics? Can one's games interactions come primarily from emergent behavior or does one need to do more leg work in the game model? Tons of discussion for later, hopefully! Also: VRTK is awesome and…

Checkout the Maptionary library, I'd like to have feedback (and any use other than myself). The existing stuff for JSON (particularly) is good if you're serializing into and out of data structures, but if you just want data? Not so nice.
Post reply on HN