The LaserBoy Thread

[dchammonds]

The important parameters are max lit distance, max blank distance, max dwell.

These determine how far you can go in any direction in one sample and how long to hang on an angle up to 180 degrees.

You can see how many vertices are in a frame. If you show vertex order as Z you can look at the side of space and see the dwell and so forth.

Be it lit or blank, distance is independent of time, but if you change point rate the velocity (or draw rate) will follow it.


Max dwell IS time, so the tick rate of the clock must be known. Wave rendering in [redacted] looks to the chosen sample rate
for its time base. Dwell is applied to sudden angular changes for visual impact- this slows down the overall frame rate.


Since ild (or dxf) files contain no point rate specification, [redacted] dismisses dwell altogether when optimizing these frames.


It just so happens that the tiki file is loaded with steep angular changes, so its wave rendering in [redacted] contains a train car
load of dwell points to bog down the frame rate.

[james]

Dwell is most certainly added to frames during optimization and can be saved to an ild file.

As far as all the optimization parameters are concerned, you have to have some way to quantify that stuff.

Make sure you get the best minimization before you optimize. Make sure you get the fewest lit segments. A dxf import is typically way out of whack and segments can be broken in many pieces. Conglomerate is supposed to do some reconstruction of that. If you really want to get into it, you can explode a single frame into a frame_set, each frame a single segment. Then you can select frames an join them back together into a single frame. Frames join together end to end in the order of the frame_set. You can select and move frames to the beginning or the end of the frame_set to change the order they join. This way you can really see what you have and totally control the order and direction of the segments.

I'm really glad you're taking some real interest into the specifics of all this stuff. It's been 19 years of development.

Actually most of that stuff was developed well before I even ported it to SDL back in 2008.

.

[dchammonds]

Dwell is most certainly added to frames during optimization and can be saved to an ild file.

Where does your time base come from?

[james]

If it's a factor that is measured in seconds or microseconds then it is relative to the set sample rate (default 48KHz).

Dwell is also progressive. The more acute the angle, the closer you get to the maximum dwell in microseconds (180 degrees).

In any event, dwell ends up being an integer number of points, so it's all just relative.


.

[dchammonds]

If it's a factor that is measured in seconds or microseconds then it is relative to the set sample rate (default 48KHz).

Dwell is also progressive. The more acute the angle, the closer you get to the maximum dwell in microseconds (180 degrees).

In any event, dwell ends up being an integer number of points, so it's all just relative.


.

That's just it. I can move the set sample rate all around and it has no effect when individually optimizing a dxf frame.

[james]

Ok. I'll have clear the cobwebs and blow the dust off of those areas of the code.

I'm seriously glad that you are finally looking at this stuff and I hope you are still learning C, C++, msys2, GNU Linux, GCC and all that other brain rotting nonsense.

[dchammonds]

Ok. I'll have clear the cobwebs and blow the dust off of those areas of the code.

I'm seriously glad that you are finally looking at this stuff and I hope you are still learning C, C++, msys2, GNU Linux, GCC and all that other brain rotting nonsense.

I've since noticed that there are some dwell points added in optimized ild, just nowhere near as many as wave@48K using the same max dwell time setting.

[james]

// LaserBoy_utility.hpp
// line 95

//############################################################################
inline int inline_dwell_vertices(double angle, // zero to pi radians
                                 int    sample_rate,
                                 double max_dwell_microsec
                                )
{
    if(angle < (pi / 8))
        return 0;
    return (int)(ceil(   (angle / pi) // zero to one
                       * (sample_rate * (max_dwell_microsec / 1000000.0))
                     )
                );
}

This is the function for calculating the number of points to add to an angle. It is linear as you can see. That is, it adds points proportional to the angle from 0 to pi radians for anything over (pi / 8) radians (22.5 degrees). And it is based on sample_rate.

Frame 16 of in.ild was designed to test for dwell.

Menu h now has two modes. You toggle between them with the letter t.

You can flatten Z on this frame to make it easier to differentiate between the actual XYZ view and the XYT, vertex order in depth ( [Tab] 1 j ). Then look at it before and after you add or remove dwell from the front ( digit 5 ) or from the side ( digit 6 ).

I think I see the issue! It is possible to keep adding angle dwell over and over again. So it is probably being added multiple times in your wave example, since you are probably optimizing in menu h and then choosing to output an optimized wav.

I'll fix that!

// LaserBoy_segment.cpp
// in function LaserBoy_Error_Code LaserBoy_segment::add_dwell()
// at about line 2314

        LaserBoy_segment    angle_optimized(palette_index, false);
        //----------------------------------------------------------------
        remove_dwell_vertices(); // <-- add this line!
        //----------------------------------------------------------------
        angle_optimized.push_back(front());

Excellent find! Thank you!

I just sneaked it into the current version. I will do another full release when I have more new stuff.

Now maybe you can figure out why the clip operator in Liquid Math can't handle an area of nothing.

James.


.

[dchammonds]

// LaserBoy_utility.hpp
// line 95

//############################################################################
inline int inline_dwell_vertices(double angle, // zero to pi radians
                                 int    sample_rate,
                                 double max_dwell_microsec
                                )
{
    if(angle < (pi / 8))
        return 0;
    return (int)(ceil(   (angle / pi) // zero to one
                       * (sample_rate * (max_dwell_microsec / 1000000.0))
                     )
                );
}

This is the function for calculating the number of points to add to an angle. It is linear as you can see. That is, it adds points proportional to the angle from 0 to pi radians for anything over (pi / 8) radians (22.5 degrees). And it is based on sample_rate.

Frame 16 of in.ild was designed to test for dwell.

Menu h now has two modes. You toggle between them with the letter t.

You can flatten Z on this frame to make it easier to differentiate between the actual XYZ view and the XYT, vertex order in depth ( [Tab] 1 j ). Then look at it before and after you add or remove dwell from the front ( digit 5 ) or from the side ( digit 6 ).

I think I see the issue! It is possible to keep adding angle dwell over and over again. So it is probably being added multiple times in your wave example, since you are probably optimizing in menu h and then choosing to output an optimized wav.

I'll fix that!

// LaserBoy_segment.cpp
// in function LaserBoy_Error_Code LaserBoy_segment::add_dwell()
// at about line 2314

        LaserBoy_segment    angle_optimized(palette_index, false);
        //----------------------------------------------------------------
        remove_dwell_vertices(); // <-- add this line!
        //----------------------------------------------------------------
        angle_optimized.push_back(front());

Excellent find! Thank you!

I just sneaked it into the current version. I will do another full release when I have more new stuff.

Now maybe you can figure out why the clip operator in Liquid Math can't handle an area of nothing.

James.


.

I just tried to do the 10 second wave rendering of the tiki dxf in this most recent update to [redacted] and I get the
same result- 3FPS.


I must have been doing something wrong earlier, because I can now see the effect that changing the wave sample rate
has on an optimized dxf frame without rendering to wave in both versions of [redacted].


I think I'm losing my mind...

[james]

I think I'm losing my mind...

You and me both bud!

Sometimes I look at the code and I think what the hell is this? How am I supposed to understand this nonsense?

root@U22:/LaserBoyV# cloc src
      57 text files.
      57 unique files.                              
      13 files ignored.

github.com/AlDanial/cloc v 1.90  T=1.61 s (27.9 files/s, 55612.7 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C++                             20           1699           5977          69686
C/C++ Header                    24            195           1857          10183
make                             1             29              4            115
-------------------------------------------------------------------------------
SUM:                            45           1923           7838          79984
-------------------------------------------------------------------------------

Try this one. (attached tiki_05)

I just found another bug!

in menu h option g conglomerate isn't hooked up to the right function.

I just sneaked another fix into the current zip. The only changes are to LaserBoy.exe (The Win64 executable) and stuff in the src directory.

I know how you analyze stuff Dean. That's why I'm really glad you are looking at all of this. I hope we can go wandering around in the code together so you can see the algorithms. It is complicated though because there are many layers to it. A function of the app is possibly many layers of functions in the code.


.