@PlaneFlightX It seems there is some sort of error in one or more variables. I kinda rushed this build out and didn't give it the same QA that I do for my usual posts so I'm not too surprised there is a broken variable somewhere lol
@jamesPLANESii Thanks! A quick explanation is that it sends the cockpit forward but at a high angle so that it is assumed that it won't hit land (60 degrees) and it uses AltitudeAgl to get an idea of the land distance below it. At the same time it is sending a "fake" ray that exists only in calculation that tests to ask if the ray existed, would it collide with the current detected land. If so, then it saves the value and shifts up the next vertical pixel to start detecting for that to hit land as the cockpit continues moving forward. This is how the system can scan an entire vertical line of the image with a single physical raycast. Kinda difficult to explain so I hope I got the point across haha
@ThatrandomguywholikesSP @IFVuser Yep, this is somewhat similar to a "LIDAR" system. Older versions of this camera actually shot out an individual ray for every pixel, which was incredibly slow. This design is exponentially faster than those designs as it can capture an entire vertical line of the image with every raycast, rather than just a single pixel.
@Numbers2 @AWESOMENESS360 @NTH These are fun ideas to use with tech like this, but unfortunately the process to take the image takes so long that it would not be feasible in its current state, and this method seems to be the quickest so far out of all my other camera designs I've experimented with 👍
@YarisHatchback That's a good idea! That was the original plan actually but it would take some big renovations in the system, so I went this direction for now
@11qazxc Hey, I'm reading your original comment 9 months later and realizing that I totally misunderstood the method you were describing for the sprites' labels. Looking back at it, I think you're right and that would certainly be better for performance. Thanks for the input and sorry for the miscommunication
@PlaneWelder My GPS was much simpler and simply moved the names on a label in the same proportion to their distance from the ship, although it had the benefit of not needing any variables. What you have here is much cooler, I wonder why you have the screen refresh from top to bottom? Is it just for cosmetics or is there a practical reason to doing so?
@FalHartIndustries Since Garrisphere has no back-side, you can seem him inside out when he turns around, causing an illusion that can be hard to understand haha
@PlanariaLab I've been able to save a lot of performance by precalculating the sin and cos functions into variables instead of doing the trig calculations for every single point which changed the game and allowed me to really push the boundaries. So far I've been reaching up to rendering 2500 points on my gaming PC. I like the strategy of rendering lines by a series of points but its disappointing there is no alternative right now for fully filled in lines.
Do you have the "InDesigner" variable to keep the points from rendering in the designer to get rid of lag in the designer? If so then that is pretty clever 👍
@32 I found the old script and did a good amount of work to make it more efficient and usable, it will take in a set of points and their colors and generate a craft that will render them in a label. Here is the link! Please let me know what you think, if there are any bugs, or if any features should be added.
@32 I had made this 3D Renderer which probably works similarly to the one that @PlanariaLab made. It essentially takes 3D points and applies rotation matrices and then projects them to 2D. I remember using this video as a guide to understanding how the math works. The main issue is connecting the points. While rendering the points themselves don't take much cpu, I don't know of a way to draw lines to connect them increasing the cpu cost by a ton. This may be a simple problem to solve for all I know but I haven't looked very much into it since my work on these are all years old. If I remember correctly, my python program I made to generate the renderer simply takes in a set of 3D points, and I might have made a V2 that could also allow you to specify the color of each point too. I can go looking for that script for you when I get the time but if I forget over the next few days give me a ping to remind me 👍
Congrats!
+1I made a really good STOL a while ago here. Crazy that it's been over 7 years since then lol
+1These thing looks so cool and goofy at the same time. It feels so... Soviet
+2@PlaneFlightX Thanks!
@PlaneFlightX It seems there is some sort of error in one or more variables. I kinda rushed this build out and didn't give it the same QA that I do for my usual posts so I'm not too surprised there is a broken variable somewhere lol
+1@Whills Lol you can go here for that
@jamesPLANESii Thanks! A quick explanation is that it sends the cockpit forward but at a high angle so that it is assumed that it won't hit land (60 degrees) and it uses AltitudeAgl to get an idea of the land distance below it. At the same time it is sending a "fake" ray that exists only in calculation that tests to ask if the ray existed, would it collide with the current detected land. If so, then it saves the value and shifts up the next vertical pixel to start detecting for that to hit land as the cockpit continues moving forward. This is how the system can scan an entire vertical line of the image with a single physical raycast. Kinda difficult to explain so I hope I got the point across haha
+4@ThatrandomguywholikesSP @IFVuser Yep, this is somewhat similar to a "LIDAR" system. Older versions of this camera actually shot out an individual ray for every pixel, which was incredibly slow. This design is exponentially faster than those designs as it can capture an entire vertical line of the image with every raycast, rather than just a single pixel.
+1@Numbers2 @AWESOMENESS360 @NTH These are fun ideas to use with tech like this, but unfortunately the process to take the image takes so long that it would not be feasible in its current state, and this method seems to be the quickest so far out of all my other camera designs I've experimented with 👍
+1@YarisHatchback That's a good idea! That was the original plan actually but it would take some big renovations in the system, so I went this direction for now
+1@LunarEclipseSP Sounds good!
+1@LunarEclipseSP Do you have discord?
+1What a gem 💯💯💯
Awesome mod!
@LoganAviation Just been busy is all. If I get any burst of inspiration I'll probably show up again in the future in some capacity.✌️
Thanks for your work, I wish this was supplied by default be the devs o7
@Sisteni lol yup that's true
@Johnnyynf fr, piston engines are pretty much how I started out on this site and I'm glad the technology is still alive
@126 Haha thanks
+1Spotlight button has never been easier to press
@11qazxc Hey, I'm reading your original comment 9 months later and realizing that I totally misunderstood the method you were describing for the sprites' labels. Looking back at it, I think you're right and that would certainly be better for performance. Thanks for the input and sorry for the miscommunication
+1This is awesome! Good job 👍
@PlaneWelder My GPS was much simpler and simply moved the names on a label in the same proportion to their distance from the ship, although it had the benefit of not needing any variables. What you have here is much cooler, I wonder why you have the screen refresh from top to bottom? Is it just for cosmetics or is there a practical reason to doing so?
+1This is awesome! Great job
+1@TheMouse Thanks!
Ha that gear is a real throwback
+1I hope it comes with Funky Trees 2 XD
+1@Solent19 Lol, I never claimed it to be smart AI XD
+1@SimpleStudent Yep, there are only 4 of the 5 slots occupied so far
+1This is awesome! I've been looking for ways to do this for a long time. Good job!
+3@PlanariaLab what documentation do you use for labels? I like use this but it doesn't have everything
@PlanariaLab Thanks for this input! I didn't know about that specifier. I'll implement that and credit you in the .py comments
+1@FalHartIndustries Since Garrisphere has no back-side, you can seem him inside out when he turns around, causing an illusion that can be hard to understand haha
+1@32 IA 3D Renderer V4.2 is out now with just some minor bug fixes that you'll probably want to use instead
@32 Np!
@32 IA 3D Renderer V4.1 is available is here! All the changes are described in the .py file but the main upgrade is a large improvement in performance
@PlanariaLab I've been able to save a lot of performance by precalculating the sin and cos functions into variables instead of doing the trig calculations for every single point which changed the game and allowed me to really push the boundaries. So far I've been reaching up to rendering 2500 points on my gaming PC. I like the strategy of rendering lines by a series of points but its disappointing there is no alternative right now for fully filled in lines.
+1Do you have the "InDesigner" variable to keep the points from rendering in the designer to get rid of lag in the designer? If so then that is pretty clever 👍
@PlanariaLab Very interesting! And thanks for the tip on the multibyte characters I've never considered that
+1@SkyJayTheFirst Thanks! And I agree, Funky Trees is great but definitely isn't the most friendly foundation for these types of projects XD
+2@32 Thanks!
Is the Mortal Kombat XL still available? I'd really appreciate it thanks!
@32 No problem, I'm here if you have any questions
+1@32 I found the old script and did a good amount of work to make it more efficient and usable, it will take in a set of points and their colors and generate a craft that will render them in a label. Here is the link! Please let me know what you think, if there are any bugs, or if any features should be added.
@32 I had made this 3D Renderer which probably works similarly to the one that @PlanariaLab made. It essentially takes 3D points and applies rotation matrices and then projects them to 2D. I remember using this video as a guide to understanding how the math works. The main issue is connecting the points. While rendering the points themselves don't take much cpu, I don't know of a way to draw lines to connect them increasing the cpu cost by a ton. This may be a simple problem to solve for all I know but I haven't looked very much into it since my work on these are all years old. If I remember correctly, my python program I made to generate the renderer simply takes in a set of 3D points, and I might have made a V2 that could also allow you to specify the color of each point too. I can go looking for that script for you when I get the time but if I forget over the next few days give me a ping to remind me 👍
@V Looks good on the Steam Deck!
@Keithisawsome Thanks! Feels like forever ago since I've made made this haha
@PlanariaLab Didn't know about that! Thanks for the info
+1Really cool! Just some advice, if you use the ControlBase part instead of rotors, you can do the same thing but without the rotor noise
@MountainMan8131 Depends on the device you're playing on, but it may take a minute to load this high quality graphics version even on a beefy computer
+1