Difference between revisions of "User:Mariomeissner/logs"

From BRL-CAD
(18 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
SOCIS 2017 Logs
 
SOCIS 2017 Logs
  
'''20-6'''
+
'''10-8'''
  
Build successfull on Arch Linux (Antergos) x64
+
Moving task over to rtexample. Including Voronoi tesselation. 0 and 1 points working, including user input (no hardcoded points).
Working my way through the Introduction_to_MGED.pdf
 
  
'''21-6'''
+
'''11-8'''
  
Successfully calculated mass of a copper sphere using rtweight.  
+
Continued working on n-point Voronoi. Todays code doesn't compile yet.
  
'''11-7'''
+
'''12-8 & 13-8'''
  
Diving into the source code of rtweight.
+
Break.
I will need some help understanding the overall structure of the repository and some details about rtweight.
 
  
'''12-7'''
+
'''14-8'''
  
Proposed an initial model of representation. I would use a three-variable function that returns the density of the material at a certain point in space. Integrating this function over the boundaries of the object yields it's mass.
+
Continue working on n-point Voronoi.
Example can be found here:
 
https://drive.google.com/file/d/0Bz6hfFobLeoyZC1vQ1JwSU05NDg/view?usp=drivesdk
 
  
'''14-7'''
+
'''15-8'''
  
Started working on the example raytrace application. I am setting highest priority to understanding the basic behaviour of this little program, as I know it is the foundation I will need in order to continue with the project.  
+
Finished initial Voronoi point implementation.  
  
I will try to modify it in some ways and see if I break it.
+
Will now continue working on implementing vectors.
  
From today onwards, I will be working from 15:00 to 22:00 most days, and from 10:00 to 13:00 as well a few days a week. After evaluating how much can be done with this schedule, adjustments will be made accodingly.
+
'''16-8'''
  
'''15-7'''
+
Break.
  
Drafted an example of how to obtain a function that returns the density a ray sees at it crosses the object.
+
'''17-8'''
  
'''16-7'''
+
Working on read_density_points to support vector input.
  
Reading through, understanding and compiling the example applications.
+
'''18-8'''
  
'''17-7'''
+
Finished read_density_points vector update and will now give support to transitions (vectors) with arbitrary 'rate' inside segment_density calculations.
  
Modeling the sword and continuing yesterdays work.
+
Moved old logs to a separate page (http://brlcad.org/wiki/User:Mariomeissner/logs/old) to keep this one clean.  
  
Starting with the candle example to get practice.
 
  
'''18-7'''
+
'''30-8'''
  
Making new, blade that actually fits the specifications; remaining time digging through the viewweight.c code.
+
Left the code in a more stable shape. Fixed some bugs, projections are now skipping.
  
'''19-7'''
+
'''5-9'''
  
Designing proper density model that allows for good implementation.
+
Finally set myself up in Germany.
 +
New objective: test out code and fix any more bugs.
 +
Took my time to set up dev environment, but couldnt work because of compilation issues.
  
'''20-7'''
+
'''6-9'''
  
Studying source code.
+
Testing and fixing code. Found major flaw in projection skipping.
  
'''25-7'''
+
'''7-9'''
  
Setting up eclipse development build and studying source code.
+
Worked on a new model to properly skip projections.
  
Facing problem where Eclipse does not properly recognize tons of symbols in the code, including basic types like "FILE". One candidate solution is to browse to the C/C++ pre-processor settings and adding and configuring the CDT GCC built-in compiler. Details here: https://stackoverflow.com/questions/21065616/multiple-could-not-be-resolved-problems-using-eclipse-with-mingw
+
'''8-9'''
  
However performing the steps on there crashes the indexer while it's updating.  
+
Implemented the new projection skipping model and re-ran the tests. Everything seems to work correctly for now.
  
I'm using Arch, Eclipse Oxygen and the latest available GNU compiler suite. I built the project for eclipse using CMake following the guide over at wiki/compiling.
+
'''9&10-9'''
  
Thinking about how the user should input the density data and how we should handle it inside, I found this to be relevant:
+
Break
https://en.wikipedia.org/wiki/Curve_fitting
 
  
We could let the user set any number of points throughout the material with specific densities, and then we can apply a simple curve fitting algorithm to  create a continuous density function. This function could be stored in some struct or array and then be used to return the density value at any given point with precision. These requested points could be used for interpolation by the calling code.
+
'''11-9'''
  
'''26-7'''
+
Cleaning code and moving over to rtweight. Once I moved I will run rtweight tests to see if mass is correctly computed for simple shapes.
  
New goal: modify the example application to shoot a ray to the object and calculate it's density assuming it's a 0 to 1 change.
+
'''12-9'''
  
Working on goal.
+
Found some more mistakes in the code.  
  
Results: [https://puu.sh/wTDzC/5c3a15af9a.png screenshot]
 
  
'''27-7'''
+
'''13-9'''
  
New goal: snippet code to read density points from command line into data structure.
+
Preparing the move to rtweight.  
  
'''28-7'''
+
'''14-9'''
  
Debugging yesterdays work.  
+
Moving code to rtweight. It's harder than expected and things don't work yet.
 +
I tried cleaning out most of the code that was used to read densities from the file, and rely only on my own function call (so that I can avoid the stupid segmentation fault I can't get rid of).  
  
Managed to make it work to a point where I think the goal has been reached. Further expansions of this goal may be made once more is known about the density specification.
+
'''15-9'''
  
'''29-7'''
+
Break.
  
New goal: write simple function that returns the density value for a material at any point in space, for simple specifications (a few density_points at max).
+
'''16-9'''
  
Working on goal.
+
Mass returns as NaN so something is wrong somewhere. Debugging.  
  
Todays work: [https://transfer.sh/PvVCy/rtexample.c]
+
'''17-9'''
  
'''30-7'''
+
Had several compilation problems. I can now compile on VS again. Density file loads.
 +
Mass now returns 0.
  
Continuing with yesterdays work. Decided to make a new structure to store vectors and their factors. We can go through the list of provided points for a material specification and compute the vectors we care about, push them to a list.
+
'''18-9'''
  
'''31-7'''
+
Break.
  
Received feedback on yesterdays work. Apparently I tried to do breadth first, which resulted in too ambiguous code that obviously wasnt working yet either.  Today I tried to revert that and made a simpler situation work. Figuring out how to properly use vmath macros and bu_lists, as well as debugging my mistakes, took away most of my time today but I feel it was an enlightening process. Emailed results.
+
'''19-9'''
  
'''1-8'''
+
Investigating cause of negative densities that end up causing the final mass to be 0.
  
Day off
+
'''20-9 & 21-9'''
  
'''2-8'''
+
Because of course registration and orientation events, busy. Break.
  
Partial day off. Woring on blade.
+
'''21-9'''
  
'''3-8'''
+
Fixing code in rtweight.
  
Finished blade curve.
 
  
Working on density(), will try to make the vector list work.
+
'''22-9'''
  
Facing a little design problem. If we have a vector_list, we need to be able to keep track of who's vector each projection is. We cannot store it inside the vector bc we will want to reuse it on other calls. One solution could be creating struct contribution and store both the value and a pointer to the vector it came from. After all we only need the factor. Calculing everything necessary (projection and contribution) within the loop and then throwing away the information has also been considered. It could work if we do average but would not work if we want to perform some other more complex operation on them.
+
Fixed several issues, mass now computes, but wrongly.  
  
'''4-8'''
+
Trying to learn to use the VS debugger.
  
Continuing yesterdays goal.  
+
Starting to get a feel on why things don't work. I'm finding and polishing several issues. I also noticed that I am not correctly handling two edge cases for segment density:
  
Separating code into my own files, and restoring rtexample to the original.
+
-First point should be a skip (for now I had assumed first point would never be one, without really thinking about it).
  
Figuring out how to set up new projects within the solution in VisualStudio.
+
-First bunch of points or last bunch of points' projections lay outside the segment. They should receive special consideration.
  
'''5-8'''
+
'''23-9'''
  
Carrying my work over to viewweight.c . New goal is to make case 0 and 1 points work while using my code. Will also model a box that will serve as initial dummy example object. Calculate results by hand and compare with code output.
+
From today I will try to approach the final step of my code in a slightly different way, in order to correctly handle projections outside the segment, but who's boundaries actually lay inside. I will use intersections to compute a list of boundaries, and then just loop through them once to calculate avg density. I will not use the projection point in this stage (I will still use it to predict a skip).
  
'''6-8'''
+
I know I should write complete code, but this overhaul will take some time. I will try to release in-progress working stages if I can. I really think this new version cleans up the mess quite a lot, simplifies the concepts, makes it all more readable, and most importantly, will support more situations than before, removing several flaws.
  
Some more tests on current code. Started working on the new 4 point example.
+
The whole projection concept wasn't that good of an idea to begin with, I shouldn't have stuck to it for so long. It's only useful for predicting skips.
  
'''7-8'''
+
'''24-9 to 1-10'''
 +
Holiday (trip).
  
Finishing off new example. Separating vector creation from query_density code, so that initial vector list is only created once. Performance of rtweight right now is not so good, this should help.
+
'''02-10'''
 +
 
 +
Refactoring stage 1.
 +
 
 +
'''03-10'''
 +
 
 +
Desiging new algorithm for stage one.
 +
 
 +
 
 +
'''04-20'''
 +
 
 +
Designed and published new algorithm and published it.
 +
 
 +
'''05-20'''
 +
 
 +
Starting with implementation.
 +
 
 +
'''06-20'''
 +
 
 +
Broke down implementation steps. Got rid of intersection function, replaced by a new, more complete function that tells us if a point's region will be crossed or not, directly. Computes the intersection, checks if it lays inside the segment and checks distances to evaluate if the boundary is crossed by the segment or not, returns a boundary_t struct.  
  
New example works: [https://transfer.sh/R8o7z/viewweight.c code], [https://puu.sh/x3MZm/d32523b6f4.png result], [https://drive.google.com/file/d/0Bz6hfFobLeoyRmI5elVlRkN2X00/view?usp=drivesdk expected result on paper].
 
  
'''8-8'''
 
  
Incorporating readDensityPoints() into the current code (writing data into the .density file) so that the whole thing is 'complete'. Instead of hardcoded data I will load it from the file.
 
  
 
Mario Meisner.
 
Mario Meisner.

Revision as of 08:59, 6 October 2017

Mario Meissner SOCIS 2017 Logs

10-8

Moving task over to rtexample. Including Voronoi tesselation. 0 and 1 points working, including user input (no hardcoded points).

11-8

Continued working on n-point Voronoi. Todays code doesn't compile yet.

12-8 & 13-8

Break.

14-8

Continue working on n-point Voronoi.

15-8

Finished initial Voronoi point implementation.

Will now continue working on implementing vectors.

16-8

Break.

17-8

Working on read_density_points to support vector input.

18-8

Finished read_density_points vector update and will now give support to transitions (vectors) with arbitrary 'rate' inside segment_density calculations.

Moved old logs to a separate page (http://brlcad.org/wiki/User:Mariomeissner/logs/old) to keep this one clean.


30-8

Left the code in a more stable shape. Fixed some bugs, projections are now skipping.

5-9

Finally set myself up in Germany. New objective: test out code and fix any more bugs. Took my time to set up dev environment, but couldnt work because of compilation issues.

6-9

Testing and fixing code. Found major flaw in projection skipping.

7-9

Worked on a new model to properly skip projections.

8-9

Implemented the new projection skipping model and re-ran the tests. Everything seems to work correctly for now.

9&10-9

Break

11-9

Cleaning code and moving over to rtweight. Once I moved I will run rtweight tests to see if mass is correctly computed for simple shapes.

12-9

Found some more mistakes in the code.


13-9

Preparing the move to rtweight.

14-9

Moving code to rtweight. It's harder than expected and things don't work yet. I tried cleaning out most of the code that was used to read densities from the file, and rely only on my own function call (so that I can avoid the stupid segmentation fault I can't get rid of).

15-9

Break.

16-9

Mass returns as NaN so something is wrong somewhere. Debugging.

17-9

Had several compilation problems. I can now compile on VS again. Density file loads. Mass now returns 0.

18-9

Break.

19-9

Investigating cause of negative densities that end up causing the final mass to be 0.

20-9 & 21-9

Because of course registration and orientation events, busy. Break.

21-9

Fixing code in rtweight.


22-9

Fixed several issues, mass now computes, but wrongly.

Trying to learn to use the VS debugger.

Starting to get a feel on why things don't work. I'm finding and polishing several issues. I also noticed that I am not correctly handling two edge cases for segment density:

-First point should be a skip (for now I had assumed first point would never be one, without really thinking about it).

-First bunch of points or last bunch of points' projections lay outside the segment. They should receive special consideration.

23-9

From today I will try to approach the final step of my code in a slightly different way, in order to correctly handle projections outside the segment, but who's boundaries actually lay inside. I will use intersections to compute a list of boundaries, and then just loop through them once to calculate avg density. I will not use the projection point in this stage (I will still use it to predict a skip).

I know I should write complete code, but this overhaul will take some time. I will try to release in-progress working stages if I can. I really think this new version cleans up the mess quite a lot, simplifies the concepts, makes it all more readable, and most importantly, will support more situations than before, removing several flaws.

The whole projection concept wasn't that good of an idea to begin with, I shouldn't have stuck to it for so long. It's only useful for predicting skips.

24-9 to 1-10 Holiday (trip).

02-10

Refactoring stage 1.

03-10

Desiging new algorithm for stage one.


04-20

Designed and published new algorithm and published it.

05-20

Starting with implementation.

06-20

Broke down implementation steps. Got rid of intersection function, replaced by a new, more complete function that tells us if a point's region will be crossed or not, directly. Computes the intersection, checks if it lays inside the segment and checks distances to evaluate if the boundary is crossed by the segment or not, returns a boundary_t struct.



Mario Meisner.