Date: February 7, 2025
Well, the semester has officially kicked off, and along with that, so has this project. I have not made much progress on the actual application yet, button at the very least, I have made some development decisions. Due to the extra fluidity, I have chosen to develop this application in Java, that way any device with a JVM will be able to run my application (though I'm not entirely sure how popular this project will get). In any case, I was able to make the decision of using Java FX for the majority of the development. Thus far, the only library I'm sure I want to import is the Eclipse library. It will take me a while to figure out the development process, but I'm confident in my own ability to learn and adapt. That's about all I have to say about the project. 'Till next time!
-Colton
Date: February 15, 2025
This week has felt like an absolute torrent. After struggling for hours upon hours with getting JavaFX to correctly import, I ended up being completely unable to get the SceneBuilder correctly integrated with any IDE I tried. It got to the point where I wasn't willing to keep going, especially after wasting close to six hours just attempting to make the environment work on my computer. After so much effort, I made the decision to switch the coding language to C# - a radically good decision, as after a short download of Visual Studio 2022, I was able to get it working within the span of an hour.
That being said, in terms of program progress, I believe I have a solid idea of what I want the final program to look like. After the Mini Grease Board session_cache_expire on Tuesday, it was thanks to the others that I realized that the best idea for my project would be to have two different form objects. The first one would detail the creation of floor plans and the placement of cameras. In terms of the floor plan, there will be a space on the first form where the user will click points which will serve as the vertices for the walls. Clicking two subsequent points will draw a wall between those spaces. There will be two modes for this: interior and exterior. In the exterior mode, the user will exit the drawing phase through a "DONE" button. In the interior mode, the user will automatically exit once they click two points. The vertices that the user clicked will be what gets stored, so floor plans can get saved and re-drawn later. The user will also be able to place cameras on this screen, though I have not figured out all the semantics of camera placement yet.
The user will have the option to switch between the first and second screen via a button in the top right corner of the screen. The second screen will focus on the camera's tracking. This screen will have the different cameras selected and differentiated via different colors in their vision cone. This will also have the algorithm for a minimum amount of cameras, as well as the calculations for the total area that needs to be covered and the total area that is covered. I have to thank everyone's comments for giving me this many ideas and such great criticism about my original idea. It's helped to make my program much less complicated.
I'm only now realizing how much I've written already. But, in any case, I know what my next steps are. Unfortunately, I've fallen pretty far behind, having only just completed a "Hello World!" program. Thus, I'll be spending most of the week next week reviewing the CS-350 C# labs that BMVP sent me to check out some forms elements I can add to my own application (and beginning the construction of the first screen). Hopefully there'll be a much better blog for next week. Ciao for now!
-Colton
Date: February 26, 2025
This is by far and away a bit overdue, but I spent a ton of time working on the Drawing Functionality and did not want to put out an update until I had two secure ideas for making drawings to begin with. Now, I've completed the drawing, so I'm putting out a quick update.
Currently, I have two ideas for drawing that I plan to narrow down and completely integrate within the week. The first is the simpler one (and truthfully the most likely to be cut given its limited functionality). To begin, the user must select the "Drawing Mode," which switches their cursor to a crosshair for higher precision. Then, the system takes note of the user's next few clicks that are not on a button. As soon as the user has clicked twice, the system draws a line and stores the most recent click (thus when the next click after that happens, another line is drawn). This loop continues until the user clicks a button that exits the drawing mode, upon which the app links the last point back to the first. While it is efficient, this system is simple to a fault, especially since it means the user cannot draw more than one shape at a time. This is why I am considering removing it, especially after completing the second plan.
The second plan is much more elaborate. Under the second system, the points are still recorded; however, a line is only drawn on two points after the user selects a previously drawn point as well as a second point within the system. This was meant to be a proof-of-concept that I did for fun, but I am now seeing the practicality of a complex system like this. The only difficult part of it now will be saving the edges as they get drawn. The plan for now (if I choose to fully implement this design system) is to set up an adjacency matrix, and save that WITH the point locations for the saving/loading of projects.
That's as much of an update as I have at this point. Next, I'll be looking into finishing the saving/loading system for floor plans, as well as adding some functions to erase edges and/or points, if I can. Although the main focus for the next while will be Camera placement, which I'm very excited for.
-Colton
Date: March 1, 2025
I'm excited to say I've made great progress and I'm looking forward to what comes next! As of now, the drawing functionality is pretty close to being finished and I couldn't be more excited. Let me explain the recent developments.
So, unsurprisingly, I ended up choosing the second plan for drawing, just in general. However, thanks to some guidance from advisors, I've made some decisions to further improve and implement the nature of the design. Firstly, I have implemented ArrayLists to track the points drawn by the user as well as the edges. Although this sounds like a bit of a strange implementation, the dynamicity of ArrayLists mean that the user has theoretically infinite points to use, but still maintains the program with as little space as possible. Moreover, this should make storing the floor plans much easier (though I have yet to fully finalize the storing of the points as of this entry being completed).
Now, for some clarification on how the drawing system works. It starts by the user clicking a button which puts them into "drawing mode," where their cursor gets changed into a cross. From here, the user can click spaces on the program to place a point, which gets added to an ArrayList of points. If the user clicks on a previous point, it gets selected, and saved into a private array of points, and in the moment where two different points are selected, an edge is automatically drawn between them and, in the future, will be saved into an ArrayList of edges (though I will have to finish designing a Class of Edges to make for easier storing). This method of creating and storing points is a fast way to store and save points and edges while also having plenty of storage space for potential users.
From here, the next steps include the finalization of drawing points/edges (which includes erasing both), storing floor plans, and loading stored floor plans. This should theoretically be the last point before I dive into the meat of this project: the camera functionality. I'm excited to keep working on this project, especially because we're starting to get into the thick of it. That's the update, thank you for reading this far! Take care.
-Colton
Date: March 8, 2025
I should have a lot more to say about this update, but I haven't made as much progress as I would have liked due to Concert performances, so here's what I can give so far. As of right now, I've been able to fix some issues with the drawer (mainly the fact that any drawings would disappear from the form when dismissed), and I've begun work on saving/loading. The biggest problem I'm having right now is the storage method for the data files (turns out writing to files in C# is a bit more complicated than I expected, which is leading to some difficulties in the writing of this all).
So far, saving/loading is the main goal before my appointment next week, as well as the beginning of camera functionality. I have yet to decide how the user will be able to draw cameras, since the previous Drawing Mode is mainly worked through the cursor's shape being different (unfortunately, there's no cursor that looks like a camera, haha). However, all will come with time.
I wish I could say there's much more than that, but as I said, not much time due to concert performances and other work taking precedence as of writing this. However, it should be very possible for me to have Saving/Loading of floor plans functional by next week (crossing my fingers). Thanks for taking time to read!
-Colton
Date: March 14, 2025
A bit of an early blog this time around, but it's mostly because I'll be in Florida for the start of my Spring Break. I've managed to put in plenty of work for the week, and I was able to (mostly) complete the Saving/Loading feature, save for some organizational issues with the files being saved as well as some unnecessary Dialogue which I could have replaced with File Directories. At this point, I have a clear idea of capping off the drawing feature thanks to some further explanation of painting via BMVP.
At this point, my next steps are quite clear: it's time to really begin camera construction. For now, each camera is going to need to be constricted to a wall, so my plan for that is to add a bit more to my Edge class: I'm going to store the slope as part of the class, so that way I can utilize the point-slope formula so that the users who want to create a camera have to pass a check to see if the place they're putting cameras down on is on a line.
Unfortunately, these changes do have to get finished over break, but considering how far I was behind, I'm glad to be catching up, even if it's only a little bit. It's still a bit weird for me when I realize that we're halfway through the semester once we get back from break. It feels like this project is so far from being completed, but I'm ready to lock it down and get progress finished once I get back from vacation.
Thanks for reading once again, I hope you have a great day!
-Colton
Date: March 26, 2025
This is the work that I managed to complete over break, although it is coming at a very late point in time. Thankfully, I was able to put aside some time to complete a good number of things; I re-coded floor plan saving/loading using OpenFileDialog and SaveFileDialog respectively so that no longer looks quite as clunky nor is it as confusing for users. Speaking of saving and loading, I reorganized the files. They went from looking horribly misorganized to being actually readable by humans, which will be especially helpful for camera storage as I continue moving into camera development.
Unfortunately, it's time for the area I'm not so proud of, and that is the current status of camera development. I'm currently struggling to properly differentiate between being "on" vs. being "off" the line of an edge. For starters, I began tracking the slope of all Edges that are on the current floor plan. Then, I created a function "isOnEdge" which is meant to track if a location given by int parameters x and y is on the edge by using point-slope form to evaluate. However, I'm a bit confused on how I can extend this so that the user just by clicking on an edge in general (which is a five-pixel-thick line) can create a camera. I've had some ideas for how to enable this, but I have yet to explore a method that works how I want it to.
Thankfully, there is a positive note to end on. Thanks to the explanation I got from BMVP regarding how forms handle Painting, I was able to re-construct a method that successfully re-draws the floor plan when the window is altered by means of a "myPaintHandler" function that triggers whenever the form triggers a Paint event (like that which happens when the window is dismissed and brought back). Thus, floor plans no longer get erased when the window is altered, and I am so grateful to BMVP for her patience with me over the course of this project. I'm nowhere near done, but it really is thanks to my advisors that I've gotten so far.
-Colton
Date: April 7, 2025
It is very early in the morning, and after a few long, stressful nights, I'm uploading this as more of a "road block progress report" than anything else. Currently, there are some very significant technical difficulties that despite multiple different angles of testing I have not been able to resolve.
The first main problem is being able to update floor plan elements by clicking and dragging vertices. Despite multiple attempts to get the screen to be updated as the user is clicking and dragging, the computer, for some reason, never seems to register the thread which runs to update the graphics as active, even when I am dragging elements on the screen (verified via Console output). However, the functions that update the points definitely work, and the vertices still move when the Paint handler gets called, even though the click-and-drag appears to not work at first sight.
Working with this, I decided to attempt to work on continued efforts to implement raytracing for the cameras. While I can say that the cameras are no longer stopped by an edge unless they are actually touching it, the new problem is defining the domain in which the lines need to get drawn in the first place. To mitigate the function that runs the hard-coded camera, I decided to activate the rays in a separate function. The function, which is called ExpandTheLine, does in fact, expand the line. However, the new problem is that it's incredibly difficult to define one universal function case that works for all types of slopes. The biggest problem is dealing with negative slopes for the rays, since for some reason it causes one while loop (or the other) to infinitely loop. I have tried a myriad of solutions, such as a: ending the function based on the color of the screen pixel, b: ending the loop based on whether it's touching the edge, c: both at the same time, but no matter what I do, nothing seems to work as I want it to. It's gotten to the point where I even attempted to draw the rays as part of the paint handler, and I've also changed the base background color of the form in hopes that the comparison would be smoother, but I'm still having the same problems.
For now, I've decided to take a break from it. Hopefully at my meeting later today, I'll be able to resolve a few of these problems. Take care!
-Colton
Date: April 13, 2025
Isn't it crazy how we're almost to the end of it all? It's definitely a scary thought since I'm still behind on the project, but I have been able to make a lot of good progress this past week. So here's the update:
Thanks to a lot of reorganizational efforts (as well as restructuring where actual drawing gets done), I can successfully say that clicking and dragging is now possible in the program! Points can be dragged to rearrange them, and the lines will be updated and re-drawn exactly as needed. I have also been able to design and implement a Camera class (this was incredibly due), which keeps track of the camera's FOV, home line, and actual location. These can be created via the "Camera" menu option, and leaving the camera creation mode is the same button as the users can use to exit the drawing mode.
Although, in my opinion, the biggest win for me was clearing a different bug. Shortly after dragging was implemented, in a meeting, we determined that there was another bug with point placement where sometimes there were certain points that would not get drawn until all the points were re-drawn in the paint handler. Thankfully, I was able to figure out and get rid of this bug by reorganizing the drawing into just the Paint Handler (the bug would occur because of some missed timings in between the Thread where the drawing was taking place before and the function that would actually create and track the points and walls. Placing it in the Paint Handler allowed for this bug to not happen, and thus far, it has prevented crashes due to Graphics objects being used in two places at the same time.
Now, for the only bad part of this update. I'm still struggling with determining where the Rays for the cameras get drawn. I've changed the strategy a bit, so here's the concept: I use the slope of the line perpendicular to the wall the camera is on as well as the point that the camera is on to determine a "y-intercept," thus setting up the perpendicular line to be tested against all the edges for an intersection, with the closest one getting saved. That *should*, in theory, allow for me to find the right wall to stop the line of camera vision on, then draw the ray from the camera to that wall. Sadly, I've either got the concept wrong or the math wrong, as this has not managed to yet produce a solution.
Once I can get the actual ray determined, I can test if it's inside the floor plan by testing how many times a horizontal line that crosses through the intersection point crosses through the edges. Once I do that, I will be able to tell because the line will cross two times: once in, once out. That will determine valid domain for the rays. But all will come in time: I still have some work I want to do before my next meeting, and I plan on making substantial progress in the next few weeks. That's all from me, for now. Happy early Easter!
-Colton
Date: April 23, 2025
So, this is definitely a bit late, but I've had some huge changes since the last update.
I can say that at this point, I'm about 2/3 of the way through having a complete camera FOV. So, let me break how the FOV calculations work, since this is something so critical for the function of the program. When the user creates a new camera, that creates a new Camera object, which stores the Home Edge the camera's on, its location in X and Y, and its FOV in degrees. However, the visual representation of the camera is calculated entirely different. How the visual for it works is that it takes the perpendicular slope of the home edge (this is very much subject to change once I know I can consistently generate working FOVs) and calculates the y-intercept for that particular slope, using the camera's location as a reference point. The program then tests every edge and finds the closest intersection point, which it then saves until the end, drawing the closest one. Most of the time, this ensures that the camera always sees until the closest opposing wall from its position.
Sadly, this is where I get into the part that doesn't work as nicely. Because of the way isOnEdge works, I cannot consistently rely on it to detect intersection points, meaning right now the distance formula for two points on a graph is the closest thing I have to a functional test. This obviously will not work in terms of actual functionality, but I'm stuck between the decision to alter isOnEdge away from my original thought or to try and implement a different test. The main problem of the way it is right now is corner functionality. As I try to calculate the side rays of each camera, if the camera is near a corner there is a large chance that the FOV of the camera goes outside the bounds of the "room," hitting some other edge at a point far off of the actual visual.
I don't want to try and design a shape or polygon for the floor plan, since that will basically require that the users create their lines in order, which would add an unnecessary level of complication. I'm sure I'll be able to figure it out. This is pretty much the last big bump in the road that I have time for, since after this, the majority of time that I have left will be spent adding more functionality to the form itself (i.e., moving cameras, deleting cameras, etc.). It's the endgame, and all that's left is to lock it in. Here we go.
-Colton