Speaker 1: 00:08 Frank math Speaker 2: 00:10 and so our recording frequencies, Oh, I really enjoy those though. I think we were talking about frequencies and interference on one of the earlier podcasts and it's really having fun during that part. What are we talking about frequencies this times James? Well, I love when podcasts go awry. That's my probably my favorite part of it because we've had many drift issues in the past on the podcast, so where audio would drift and things would overlap or they'd get scrunched together. We haven't had that in like hundreds of episodes, so that's good. But sometimes we have microphone issues, sometimes they're static. Um, sometimes there's popping, I was just listening to the talk show where Gruber said that he had gotten the new MacBook pro and he recorded, but there was like a mumble. He sound in the background but then he can't reproduce it at all or whatever. Speaker 2: 01:02 And then literally last week on the 10th, so January 10, the new Xamarin podcast came out that are recorded with Matt soak up and I saw him, good lawyer, said this is how I was talking at 48 Hertz. And, uh, um, and then someone commented, they said, so that wasn't your natural voice. You weren't sick, you were just, you're going to play him the hardware, you're going to find the recording equipment wasn't just a down day. I don't know what happened necessarily. Um, to be honest with you. Uh, so that is fascinating. You did find a fix. So I sent the I the clip to you and you said, Oh, I know what happened. You use it, the frequency is off. And uh, I dunno, how does sound work, Frank? Yeah. I, this is funny because it happens when we record some times when the voice over IP is acting up and it's just a matter of a reminder. Speaker 2: 01:58 We were talking about pipelines and queuing systems, receiving data and outputting data. It's one of those systems and sometimes you're not fed data at the speed you need it fed. And so you do corrections to make up for that. One of the worst, but easiest corrections you can do is just stretch audio out to make a take up the missing time and all of that. And I think that's what happens a lot in our voice over IP calls. But in your case, I have no idea what caused it or then, yeah, I totally recognize the sound and fortunately knew that a audacity, the amazingly free audio program that the entire world relies upon has a very simple menu you can click to fix it. Very true. It's very true. Um, yes. And one other correction I want to make real quick, Frank is to two corrections. Speaker 2: 02:45 Um, one correction is last week we talked about magical drones that are flying as fireworks and those apparently were not live. They were a prerecorded one and some speed up things there were drones. But um, our listeners corrected us that um, that those were in fact prerecorded ish facility. Oh no. They said, I mean, they were real drones recorded in the air. They just didn't happen at the exact moment that the stupid calendar changed over to a stupid new random arbitrary date. So whatever the spectacle is, remains, it doesn't matter when the spectacle happened, you know, fireworks shows in America are never on time for the holiday. It's always like a day before or a day after, so whatever. That's very, very true. Yeah. I mean I, I will say that I didn't do my due diligence necessarily on Emmy. I just read the article, I looked, it looked legit to me. Speaker 2: 03:44 So I, I don't know that, that's sort of my, my breakdown. But I guess I didn't read enough of the articles so I do apologize to anybody that was like, Oh, I'm there. And I also do want to do one other thing, which is I'm trying to find it now. I can't find it. This is the feedback section. Are we cleaning out our backlogs here? Yes. Oh my goodness. Where's it at? And that's a negative feedback. I don't deal well with negative feedback, James. No, no negative feedback. Oh, I can't find it now. I'll find it by the end of the episode and go from there. I wanted to give an update about last week's episode or we talked about a bunch of stuff and specifically my manager Joseph, he had recommended a podcast to me where the individual talked to him, talked about, Oh, here it is. Speaker 2: 04:37 Problem solvers. So a problem solvers is a podcast. And Joseph was like, I heard, I heard the, you did a podcast on making a podcast. He's like, I also recommend you a podcast about people making podcasts. He's like, and again, he love, I was like, okay fine, I'll correct that. So Joseph, thank you so much for giving us the spark of inspiration for last week's podcast and actually definitely, totally listen to this. Um, it's a really great podcast called problem solvers. It's usually an interview show where the hosts, uh, interviews people about problems that they're solving. Hence the name problem-solvers. I think it's from the entrepreneur entrepreneur website and episode one. We recommended it once. It hasn't come up before or is this just like a deja VU moment for me? I can't quite decide, but either way keep going on cause it's sounding really good. Speaker 2: 05:25 Yeah. So this one is a special episode one hundreds. It's how to make a podcast. And he goes in a little bit different because his show is an interview show, which is very different than our show, but it is insightful. So if you like the last week's episode, I will put a link to problem solvers episode 100 into the show notes for your enjoyment. There you go. There's my corrections. Okay. Okay. At that I still feel like it's a little bit of, I'm a thin of podcasts to talk about podcasts but I know before I started making a podcast I did really enjoy hearing people Speaker 3: 05:58 talk about you know what, I take it back actually do enjoy hearing the podcast or talk about how they make their podcasts cause you're always just a little bit curious even if it is a little mundane. So I guess I somewhat think of it as a bad thing but I'm still happy we do it from time to time. We break down and we talk about the podcast on the podcast, but that is not what we're doing this week. We are back to great developer content because I had the honor and the privilege to go over to studio Frank and studio Frank. It is a smorgasborg of all sorts of goodies and Bitcoin mining and craziness that's going on and machine learning towers of joy. And then I got to see some brand new hotness that you're working on. And it's a very different departure from what I've ever seen you work on in the past because this is the most visually pleasing three-dimensional application ever. Speaker 3: 06:54 Now, we're not gonna talk about the specifics of the app cause I don't think you're ready yet and I don't want to ruin anything, but it intrigued me because, um, it's a full beautiful Xamarin application and it's using something and I don't know. And I was, I was in [inaudible] because there's so many, so many people come and they say, Oh, I want to build a, an app and I need some three elements or I need some threeD models in it. And everyone's like, I need it to work across all these things. And what's the magical, crazy framework to do that? And I was enlightened how Frank Krueger, the Frank Krueger, built this 3d app of awesome and what tech was behind it. And maybe you want to talk about that today. Yeah, I absolutely do want to talk about it. Um, yeah, I'm totally not ready to talk about the app that I'm making, but I've had a really good time building, what should I call it, the user interface of the app and using a three D engine like you said. Speaker 3: 07:47 And thank you so much for calling it visually pleasing. Uh, it's always nerve wracking showing something to someone. I'm listening to every word. Everyone will reaction you make. In fact, these suggested, uh, two fixes immediately and I put them in immediately. So I really appreciate you, uh, being a beta tester, but yeah, let's talk 3d engines. James, now I know you are an ex game developer. I have you been keeping up on, um, 3d engines? No. Uh, uh, you know, we built our own 3d engine when I worked at crunch time and our own engine and this was pre Exxon a for game development. And there was, there was the immunity still was getting started at the time. So at this point in time there was the unreal engine and things like that, but I think it was really expensive. So we're like, well, build our own. And, and, uh, we did that and it was, it was all C plus plus and craziness. But I imagine that for most individuals when they think of 3d engines that are cross-platform, they think of unity and because that's sort of everything Speaker 2: 08:56 now kind of in a way. Yeah. Especially in our bubble. Well, the deal is, um, I, I love 3d programming and I love going from the ground up, you know, writing all that triangle shader code and all that. But the truth is you don't want to waste time doing that. That is all time consuming and terrible. And so you pick out 3d engines, which are just a higher level of abstraction over say the API that the system provides. Were you an open GL shop or a direct ex shop? Direct decks asked for the Xbox three 60. So I believe we're all direct X, Z on that point from my understanding. Yeah. I was an open GL person. I learned direct X at some point. Um, and I love writing those kinds of apps. Actually my very first iOS app is in fact an open GL app. Speaker 2: 09:47 It wasn't a 3d app though. It was just the fastest way to render on the iPhone. And so I wrote the app using open GL. So in a lot of ways, this is going back to my roots, uh, going back to using a 3d renderer as the UI. And I'm really excited to do it again. But this time James, I decided to use something called seen kit. Uh, I know we've talked about it before and actually you guessed it cause you, your first question was what is this? And then two seconds later you said this scene kit and I'm like, yeah, James scene kit baby. Yeah. It's a super duper powerful 3d graphics framework from our good friends at Apple. I don't know if you've heard of this small little startup and um, Cupertino. Yup. Yup. Little, yeah. One Apple loop plane, something like that. Speaker 2: 10:44 And I think Apple, yeah. I mean this one is the one that you see of the little toy car that's driving around running into thing that that is seen kick. Correct. You know, I don't think of that because the file new project in Xamarin and I think an X code also is a little spaceship. So I always think of this little spaceship as the kind of hello world into scene kit. But it actually came out and God, when I, when I saw this in the documentation, I felt really old, really fast. It came out James in iOS eight. Oh wow. It's old. It's been around. Yeah. And um, it's just gotten more and more powerful since the beginning. So, uh, we'll take a step back and let me describe a little bit of my initial reaction to it and why I liked it. Number one was I was at WWDC and Miguel thing and I were sitting in a little, uh, uh, column talks things, videos session and it was on-scene kit and I had a great time. Speaker 2: 11:50 It was a very impressive API. In fact, they did the whole presentation bill in a scene kit. It looked like a two D presentation, but they had like weird 3d integrations with it and then they've like really pulled back the curtain and showed how the whole thing is 3d and they started flying the camera around in the presentation and it was hilarious and it just showed how much effort and time they put into it. Um, I can go into a list of all the things I love about it, but I'll take a breath and let you say something. No, no, I, I, I believe I remember you either telling me about her or something else cause I remember before that or it might've been at the same time, there was Speaker 3: 12:27 Sprite kit. Um, and that's, uh, for today games, it's the equivalent now is iOS seven. And I know that was a lot of excitement around it because before that you had to use Coco to D, which a lot of people still use today. I think for 2d gaming and spray kit came out to be sort of this super high performance. Um, 2d I mean they call it a two D game engine, but it's really just for any 2d content. You can do crazy smooth animations and I think it has a, you know, a physics engine in it. So it's has more to it than just what UI kit would have. Because when you think of two D you're like, I could just use a UI kit and that's two D but this has the whole sort of rendering a loop to it. And then seeing care brought in the three D loop, I would assume Speaker 2: 13:18 pretty much. Yeah, I can even, um, we can have a little bit of fun and compare API APIs at the Apple level. So iOS was kind of special because it came with a high performance rendering library called core animation. And UI kit is actually a library on top of core animation. That's why you eye kit is so flexible. It's so easy to animate things because it was built on top of a high performance renderer. Well, Apple decided let's write a new renderer called metal and that is now our low level graphics API for doing super high performance. Um, graphic stuff, but also as we've talked about in the past, um, neuro networks and all that stuff. It's just a way to access GPS, basically metal. And on top of that they built a Tutti library and a 3d library. Uh, number one spike it and number two scene kit. So that's it. That's her nice little history breakdown. Hmm. Speaker 3: 14:16 There's a also fascinating is when you go to the Apple documentation, they have all these things broken down because there is a core graphics quarter image, core animation. So there's kind of three kind of go together. There's metal, metal performance, shader metal kit, and then we also have courts as well. Yeah, Speaker 2: 14:42 that's the old old tech. That's pre core animation. Yeah. Speaker 3: 14:46 And gel kit. And there's like three versions of open GL or Oh, there's open, open GL and Speaker 2: 14:52 open GL. Yes. Right. So there's a lot of ways. It's fascinating. There's so many ways to do graphics. Why did you settle on scene kit for this application? I guess? Well, quite frankly, because it does all the heavy lifting for you. It's a beautiful API. I'm just sometimes attracted to wonderful API APIs. The big joke in graphics programming is on day one you spend all day just trying to get the screen to not be plaque, you know, how long does it take to render a triangle basically. And in seeing kit you add an object and thank God they got the defaults right? You can actually see an object when you just add it and don't change any defaults or anything like that. And so just number one you had me at, it's not a black screen. And then I ended up just being an efficient API. Speaker 2: 15:43 The more and more I read the documentation, the more I appreciate it. It's design. They seem to have learned a lot from how core animation works. And so there's a lot of animatable properties on things. So you can set the size of an object and animate it to a different size, set the color animated to a different color. Um, I can just keep going on with a list like this. The, the, the material system, James, the material system is wonderful. So anyone who's done graphics programming knows you start out with your primary colors, red, green, and blue. Eventually you add texture maps and then things get nasty after that. You start putting in hack after hack of trying to make things look good. But seeingK has what is basically become an industry standard now and rendering technology, it's called, um, usually PBR, a physically based rendering, I think it's from Disney or Pixar. Speaker 2: 16:40 One of them wrote a paper on how to do it and basically every graphics engine in the world just copy and pasted the code from this Disney paper into their shaders. And it's been an industry standard for the last five years. And it's to the point where even movies use this technology, they just do it at a grander scale with more polygons, et cetera, et cetera. Um, but it's still like kind of fundamentally the same rendering technology and it had that baked in. How can you not love this API? I like that the, a lot of their API is just sort of do everything for you. So yeah, pretty nice. And, and you know, if you're a low level, you know, type of developer and you want to get into the, the open GL or the metal, like those are available to you. But this kind of gives you the best of both worlds I would assume is you get the power of that, but you get a easier programming model. Speaker 2: 17:35 Yeah. And it's not just easier. I, I fundamentally believe I one have written this app without a library like this. Not to say this API is unique because we can go into all the other libraries out there that they totally ripped off, I mean coffee and pasted like their API matches theirs. But, um, you need a high level API and it's been a little bit frustrating that um, a lot of modern UI frameworks and I kind of blamed the web for this. Uh, don't include good 3d components. And then before and them at all, I should say, uh, w P F the wonderful WPF that thing did 3d right. It was baked into the core renderer. I used to work next door to the team that tested it. They tested the most ridiculous scenarios. They had demos that would make you scream today. Like I didn't know WPF could do that. We were doing it 10 years ago and it works. It was stress tested, it had beautiful 3d integration and then they dropped it all in. UWP you're just like, Oh, come on. You know, you had such a cool Avi. So it's a little, I find it annoying that, uh, um, uh, we had this downturn in 3d but I think with VR coming up, AR coming up, um, APIs have to take three D a little more seriously again. Speaker 3: 18:56 Yeah, yeah, I think so. I mean, and, and adding the, you know, three dimensional aspects to some applications can add a lot of, I mean, new interactions that you would have. I would say that the application that you're creating is not a game, right. As an application, um, is something that I wouldn't have thought of. You know, I think when people think 3d they always think games because there really aren't that many applications off the top of my head that I can think are using 3d as the primary input. In fact, I think that the, your entire surface, everything is 3d even there's some menus to, you know, modify the surface I would say, but you're adding and removing, but even pop over menus are in three D things at the same time. And I was like, just everything is three D. um, but I thought, well it was nice about it is that it not only, you know, represented physical space of, we interact with 3d things every day, but uh, it had a lot of niceties to it, which is, it had volume. It had, um, lighting associated with it and, and, and I was Speaker 2: 20:09 sort of interacting with the real world in a way, if that makes sense. Which you can't really do on a two D flat surface because the, the world is not two D right. It's everything is 3d around us. [inaudible] thanks. I'm really enjoying all that. I'm taking all those as compliments and ignoring every bit of content that you're actually putting it now. Um, I, I, you did say one thing when you were using it, you said, Oh, you went skeuomorphic and I, I really laughed when you said that because I hadn't thought of it that way. No, I had actually considered that, but I not doing 3d for 3d sake. So during this podcast I could sound very misleading because I love 3d engines and I love thinking about renderers and all that stuff. Um, but the truth is like, I'm not going to do it unless I think that there is a purpose in the app to have it. Speaker 2: 21:00 What purpose is it serving? It's not just a little graphicy thing though. It could be, I guess. Totally. Um, but in this case, and without getting into the details of the app and we'll do that eventually, um, it's there for a reason. Um, there is a goal I'm trying to achieve with this app and it's critical that it be 3d to achieve that goal. And so I'm a little happy that, um, I was able to align a real purpose in the app with something I desperately wanted to do and know, just tell my boss that it's all for business purposes, not because I wanted to do a three D app. Yeah, yeah, yeah. That's pretty nice. Is there anything in scene kit in this application that you didn't think that you are going to add to just sort of came out of it? Or what are some other sort of selling points to the scene kid that they kind of major up? Speaker 2: 21:51 There's making rap unique? I would say. Well, I would say one thing that I started in the beginning with, and this is something I heard about, I think it was Mario brothers and they said they wrote the most simple version of the game when Mario was just a colored rectangle, you know, very programmer are the ground was a solid color of the backgrounds of solid color. And they just worked on the game mechanic of Mario jumping and Mario moving and they wanted to get that right. And so when I started this app, um, I actually started out with the question to myself. It was a real, it was a research and development kind of thing. Can I make it so you can drag objects around on the screen, feel good. There was no other purpose to the app than that. So it was kind of touch first. Speaker 2: 22:39 Like can I make an iPad feel good? Because my biggest complaint with 3d apps is they make movement in them. Feel terrible. You feel afraid to move the camera, you feel afraid to touch things, you have, you feel afraid basically. Every moment I'm in a cat piece of software, I'm on the edge of my seat, my shackles are up. I'm just a little bit, you know, scared. And I wanted the opposite of that. And what I found was seen kit this, this is so basic man. And especially if you work in a big company, you can take things like this for granted. But they had really good hit detection. So when I put my finger down, tell me what three D objects someone's touching. It's a harder problem than you think. Sounds so simple, huh? But it's harder than you think. And James, I kid you not. Speaker 2: 23:26 One of the things that made me fall in love with it was just how good their hit detector was and that I could use it so flexibly and to create the kind of touch interactions that I wanted to achieve. Well, yeah, I fully understand the complication of hits is action because I programmed a lot of that into our game engine and okay. And the, you know, there's, there's banking, there's rotation, there's, there's another axes on top of it. There's only adapts, but there is, um, you know, rotation on top of it and, and, and it's quite complicated. And then adjusting that for touchpoints is even more complicated if you're, you know, traditionally you would like get the X, Y coordinates and then loop through some stack, but you also have depth to it now, which makes it very complicated to figure out what's actually being touched. Speaker 2: 24:16 Yeah. It's funny how they took a lot of the simplicities of 2d UI development and applied them to the 3d world. So all those coordinate transforms that were that you and I are thinking about but not talking about yet that we had to do when making all this stuff work. They're terrible, they're nasty. I've been doing this stuff my whole life and I still make mistakes constantly. I get the order backwards. I get, you know, I always get something backwards. It's guaranteed and um, but with the API they have, they have a very simple object called a scene node. This is basic fundamental. It doesn't render anything. It just exists. But it has a, um, a hierarchy. So you can add nodes to nodes and you can transform them from their parent node. It's a very basic, um, skeletal system that we all take for granted. Speaker 2: 25:08 But in nice Apple fashion, they just made the API good. They made it thread safe. They made an animatable. They made those transforms that we don't want to do. You can simply say, node, convert this matrix over to that node and then apply it to this other node. They just made those annoying things easy. You know, it's just the pleasure of a good API. Yeah, that makes a life easy. I would say. Yeah, I still have a million matrix concatenations in my code million multiplications and I definitely still get the order wrong and parts, in fact I showed you importing this one object and I'm like it kind of imports, but a few of those matrices are wrong and I haven't been able to figure out which ones are wrong. So it's not always perfect, but you know, if it takes care of the 90% case that makes me happy. Speaker 2: 25:59 Just don't make me think 90% of the time I'm semi willing to think 10% of the time. Got it. But you know, I'm, I did something kind of terrible. So it's a, it's an iPad app primarily, but I decided to make um, a Mac version of it too. And so all of that wonderful touch code that I was so concerned about that I really wanted to nail, I then had to make it work on a track pad and on a keyboard and then using a mouse and Oh my God, James, I just, I did not know what I was in for. They're now a malice that should just work because that is a, uh, a digital mouse that a digital finger, right? That should just work. No, no. Oh, cause a mouse has scroll wheels. Scroll wheels should work, right? Yeah, yeah, yeah. But I mean, your mouse movement and then a single left or right click that should work out of the box. Speaker 2: 26:54 No, Nope, Nope, Nope. Not so simple because let's go back to touch code. Uh, if you have a tiny little object on the screen and you want to actually be able to touch it and drag it, then, uh, you need to create like a hit box for it. A bigger thing around it that's not visible, but that you can still interact with. So if you want to switch to a mouse, then you have to use smaller hit boxes. Otherwise people get frustrated because with a mouse, you can do precise clicks. And if you're not tapping the exact right thing. So, you know, already there's one fundamental difference. And then with a mouse, um, you also have expectations in three D software. Now, this is a wonderful place where every piece of 3d softwares inconsistent from every other. I downloaded like every piece of Mac 3d software I could get for free and sell, tried to see what they did for um, you know, camera movement and mouse movement. Speaker 2: 27:50 And they were all different. Of course, of course they were all different. So I tried to settle on some best standards, but no, it's a mouse is actually, I find to be very different from the touch pad, uh, in this world. Yeah, I would, I would think that the keyboard would be quite difficult because if you have a bunch of objects, you want to maybe tab through them and, and, and also move around items. And then you have to, you have to give visual indicators to, I guess, or you're doing even more drawing on top of it that maybe you didn't have to do before. Because if you're touching it, then you're moving it. But if you're not touching it, then there needs to be some other visual indicator on the screen. So how did you solve that? Oh, well the truth is I don't have great tabbing around. Speaker 2: 28:37 Thank you. I'll add that to the bug list. Thank you for testing my software again. But um, what I have is support for a lot of like the alternate keys, especially when interacting with the mouse and the track pad. So if you hold all different things happen, hold command, different things happen. Now here's the trick on the iPad, we also have keyboards. Um, but the only keys he can get are um, like, uh, command keys, command S, command T, command V. you can override all those and bring up a nice menu. It's great. Uh, so I have back kind of support. So that's kind of nice. You get to share a little bit of code between iOS and Mac, but of course they implemented in completely different ways. Gotcha, gotcha. So was there any differences in seeing Kip between Mac and an iOS and iPad O S or is this pretty much spot on the same? Speaker 2: 29:33 Oh, great question James. Wow, I didn't want to go here, but you just opened up a million thoughts in my head. So one nice thing is I would say fundamentally they are identical. They're pretty, now they're, they're very similar. They're very, very close to each other and it works out pretty well. But there are some fundamental annoying differences. Um, how do you put a texture map on an object? On iOS? You assign it a UI image. How do you do that on a Mac? You assign it an NS image. Yay. Now all my code has to deal with that. You know, tiny little difference. It's a tiny little difference, but like it bubbles up, you know, it affects code in funny and random ways, especially because in Mac the zero zero coordinate is at the bottom left of you. Oh no. Yeah. And yeah, yeah, there is a flag you can sack called like his view flipped and that kind of changes things. Speaker 2: 30:32 But here's the joke. It changes about 50% of things. And so then you got to figure out which things it doesn't correct for and re correct for all that kind of stuff. It's actually kind of nasty. But, um, you know, with catalysts coming out, these kind of differences won't matter. So much anymore. I think if I had started the app this year, I would have done it in catalysts probably, but it's older than that, so I deal with these kinds of silly problems. Did you end up using conditional compilation using directives or something like that? Or is it just literally two different libraries of duplicated code? I, here's what I didn't want to do. Um, I decided to use scene kit after a lot of debates and the greatest debate was, or the biggest problem I had was that it's not cross platform. And that meant I had better have a darn good reason for using it because I'm leaving behind a bunch of platforms. Speaker 2: 31:30 And what I decided was I wanted to make sure that I could use all the, basically all the, I want to say newest APIs, but that's not actually what I mean. I want to be able to use all the platform APIs without hesitation, without having to worry whether they're wrapped, whether this or that, if it exists on the platform, I just want to be able to use it and not always go through a third party. No arbitrator. You know, not wonder if it's supported here or there. It's in the platform, it's supported, it's going to work. And so when I did this, um, the Mac version of the app is actually a funny version of app kit that I wrote or a funny version of UI kit that I wrote that runs on top of app kit. So I took all the bits of UI kit that I use for the iOS app and wrote a for app kit. That sounds terrible. Let's not talk about that. Speaker 2: 32:24 It sounds like you created your own little project catalyst there. Um, so we'll have to, well, let's get into it then. Actually, cause you brought it up. I wasn't gonna ask you about this until later in the pod, but um, so what about other platforms, Frank? What about, you know, things that aren't from Apple and what are you going to do about that or you just don't care anymore over it? Uh, that I'd let the cat out of the bag on that one. You know, I wanna I wanna I want that serious talk, serious talk. Uh, traditionally I make most of my money on Apple platforms period. Um, as much as I wish I made more money on all the others, it's just the truth of the matter. And so me giving up a few platforms isn't the end of the world for me from a financial standpoint. Speaker 2: 33:11 I find it frustrating from an engineering standpoint that it's 20, 20, and I'm still having trouble executing on multiple platforms. I feel like that's a very basic thing. Um, but for reasons we can get into, um, I had my reasons why. Um, I wanted to be able to use API APIs also, but it's, it's an, it's a lot of fields, a lot of fields, man. Let's keep digging in. Ask another question. Well, I think in, you know, when I approach any application that I do, I always have to think to myself and say, you know, it's okay if I'm not, I don't have to be day one on every single platform. Uh, I would like to be. But realistically, if I'm building an app and I think that it'll be best for desktop application, maybe I start building a Mac and a windows application or I think it's best for iOS, I think that this is like an iOS audience and maybe I'll just do iOS or maybe just Android, you know, or really focus on one of them first. Speaker 2: 34:18 You know, if as an independent developer and a solo developer, it's, we've talked about it many times, it's hard to one develop for all the platforms, tests for all the platforms, regardless of any framework or no framework that you use, right? You're other developing it multiple times, testing it multiple times, going through app reviews multiple times, you know? Um, and that, that's how it's complicated. And I think in this area it sounds as if you sort of said, Hey, you know, for V one through ax, this is, this is what it's on. And if I get the user demand and feel that there's going to be re, you know, there's a risk versus reward, a payoff for doing all the work, then you know, the door is open, right? You can bring the C sharp over and then redo the UI, but I'm assuming quite a lot of it would still be reused. Speaker 2: 35:13 I guess it would be the 3d layer. The most an interaction. Yeah, you nailed it. You really nailed it. Wow. That was everything I wanted to say. So I'm just going to repeat a few things you've just said. Okay. Okay. Um, yeah. Uh, so let's talk about the energy costs. The maintenance costs. Number one, it's a development time cost to be cross-platform. Even if you have 100% code between all the platforms, you've still got to run that thing on a device from time to time. Make sure the UI fits that device. You know, there's always plat for me, things that you have to test and take care of. Um, this app has been very difficult for me to write because I kept over engineering in it. So that's, that's on me, that's my fault. But you know, it wasn't just over feature engineering. I would insist that it be cross platform and I would put a lot of effort into making sure it was cross platform. Speaker 2: 36:07 I'd insist on features that would work on iOS but wouldn't, or sorry, other way around. They would work on a desktop but wouldn't work on iOS, you know. And so a lot of me getting this app written required me to simplify it and keep simplifying it and keep simplifying it until it was something that I could finish because I had started this app so many times and I just couldn't finish it. So it was, I was just kinda merciless when I decided, um, um, stop worrying about cross-platform. Just I know iOS, I know UI kit, I can write an app and that would my blindfolded basically. So yeah, that's definitely there. And then you hit on it. Let's say this app is an amazing success and everyone's just begging me, come please forward it over to windows or Android or whatever, whichever. I'd probably do windows first. Speaker 2: 37:02 I think it make a better desktop app. Um, I did a little test run at this I reimplemented UI kit and app kit. Like which parts of UI kit am I actually using now? I know that subset, uh, the entire time I was using scene kit, I was basically learning how it works and I've written 3d engines before seeing kits, just an API. I can rewrite the scene K API on top of open GL. So if this thing is a wonderful success, there is no technological reason why I can't pour that very thin UI layer and that very thick admittedly rendering layer. But you know, I technically have the knowledge and skill to do it, um, over to a different system. The fact that I started out in.net enables me to do that cause you have the rest of the app just goes over. I just have to port those two, two chunks for sure. Speaker 2: 37:56 But that's all it is. That's just effort. It's not hard. It's just effort. Yeah. Time and effort. That's all it is. Yeah, yeah, yeah. So it was nice to simplify my workload so I could actually get this done. The app done. The app was already ambitious. So narrowed down the engineering, uh, what, what do you call that spectrum domain? Narrow it down so I could actually finish the puppy. Nice. Well you know, I don't know actually how far in the development cycle you are and if you can, you know, actually give insight into this but picking scene kit and picking, you know, the platforms Speaker 3: 38:36 that you did, you know you still have a lot of platform support, right? You're supporting iPhones. Probably if I know Frank Kruger probably like all the way back to the iPhone three G and then you're supporting, you know, iPad O S and you're probably supporting a Macko ass, right? Different versions of it. Are there lessons learned from your experience building a full app with scene kit and additionally, what I, what I mean is also across all of these platforms because I can't imagine that magically everything that you did just worked on all three platforms with no issues at all even though seeing kids. Amazing. Right. Speaker 2: 39:14 Right. No, yeah, exactly. That's a leading question sir. Cause you know the answer to all of this. I know when I first, uh, sent the app out, someone used it on their device and they said, Frankie can't possibly ship this. It runs terribly on my ancient iPad. Oh no. Well you shouldn't have installed it on an ancient iPad. But it made me feel terrible. I'm like, you know, it ran great on my iPad. Pro was my response to them. So I had to sit down and instruments profile it, profile it. I still profile it, man. I learned so many with every app I learned so many performance lessons. But in the case of seeing kit, it just has some big whopping Boolean values that you can toggle on and off that will drag that machine down to the ground or let it run at 60 frames per second, you know, just a few bullions away from total annihilation. Speaker 2: 40:09 So, um, what are a few fun ones? Um, James, I've totally fallen in love with field of view. I think every 3d renderer needs field of view. Did your game have field of view? Uh, it did not. No it did not. It was, this was in 2000 the wrong thing. I mean it's be saying focal depth, but I think you understood what I was saying. W well there, yeah, I was thinking that blurriness but basically yes, yes. Blurriness, APS need blurriness. Um, it's a great way to make things feel large or feel small. It's, it's a, it's a little optical trick cause like our eyes can only focus on one thing. So if you want to make something small, make it in focus, make everything else blurry, all sun. It feels small and I just fell in love with that effect and it runs wonderfully on a Mac. Speaker 2: 40:56 No problem. I test it on old Macs. I tested on virtual machines. No problem. No problem. You put that thing on an iPad pro and it crawls to 40 frames per second. Can't have it. James 40 frames for a second. I demand that my app runs at 60 frames per second or 120 frames per second. None of this 40 stuff. So it was sad. Um, basically I've had to go through tons of options within the app and test it on a variety of devices. And the criteria I decided to go with, and I'm still debating this, but I basically set the graphics quality so that on every device it'll run at 60 frames per or you know, as fast as the device wants to render it. And then, but I still give you a dialogue box where you can go and turn on those effects. If you want to watch your frames per second drop. Speaker 3: 41:48 I would like to see my frames per second drop as much as fast as humanly possible. Speaker 2: 41:54 It hurts though, cause the effects really, it's amazing how good 3d renders have gotten. You know, I basically took 10 years off from doing anything seriously. 3d and they've just gotten so good, um, affects that you used to need a Ray tracer for are just kind of on by default. Now they're not gray, you know, reflections aren't dynamic. Shadows are still garbage, but you know, they're trying and they're there and I love that it's, it's a simple API away. Anyone can go in, create a scene view, throw a note on it, throw a sphere onto that node, add a light and turn on automatic camera control, turn on automatic lighting, throw that thing in AR and you have a 3d app. It's like four lines of code. It's so cool. Done. Speaker 3: 42:43 Do you think you're going to infuse all of your 2d apps with random 3d things all the time? Like is is Calco gonna get cause the READi graphs. Speaker 2: 42:53 Oh, okay. I was, my initial response was no, that's silly James. You got to use 3d where it's needed and there really is, I'm anti the anti thing that we use on two D graphics and taxed isn't the same as the anti-aliasing we use on three D graphics. So there was always this like slightly different look to a three D rendered stuff to then to um, a proper two D rendering. So I'm still not comfortable with that icky ground. So I still feel like you should be in one world or the other world and not mix them too much. But that said 3d graphs. Absolutely. I love it. Speaker 3: 43:34 I love it. Anything else you want to talk about on the, on the scene kit? Speaker 2: 43:38 Uh, Nope. Um, just a couple quick other favorite features real quick. Cause I love typography James. And you can actually put text into the three D world trivially. There's just a dot. Text property property. You can even animate it and you can put emojis in it. It actually does correct real rendering you've done 3d you know that, that's the worst thing. Isn't that wonderful? That's awesome. The best I knew you'd appreciate that. I just wanted to tell you because they do text, right? It's a small miracle in 3d Speaker 3: 44:09 [inaudible] D by the way. It's also quite complicated. Speaker 2: 44:12 Yeah. For real. For real. Yep. Cool. Well thank you for letting me nerd out about 3d eye. I had so much fun writing that part of the app. The rest of the app was pain and suffering, but that part was fun. Speaker 3: 44:27 Well, I'm glad that I can learn more about some of the cool things that you know, I forget are to me because you know, seeing kid did come out a long time ago and I remember watching a lot of those videos and then I just sort of forget that I can do this stuff. Like I could do it. So thank you Frank. Yup. Awesome. All right, well I guess that's going to do it for this week's podcast. We did it. It's almost like we're getting better at it. We never know where to end, but we found a spot here. James, here is where we're going to end it. All right, well thanks everyone for listening and of course you're making them 3d awesomeness. Let us know. Write in, go to merge conflict out of fam or tweeted us at merge conflict FM not at merge conflict. That's not us at merge conflict FM. And we apologize for, uh, I think it's Dan who owns that, um, that owns that account, but we appreciate it. Sorry Dan. Uh, well have an amazing weekend, Frank and hope everyone has a great week. We're recording on Friday. Spoiler alert. So it's going to be weekend time and thanks everyone for listening. And uh, yeah, that's about it. So it's all next week. Speaker 1: 45:32 James wants now, and I'm Frank Krueger, that gorillas piece.