Hologram

Post your work-in-progress and completed skins to share and discuss.
User avatar

Re: Hologram

February 17th, 2016, 2:02 am
killall-q
   [285 posts]

Hmm, I'm not sure if that would be more efficient. Based on our earlier discussion, I tested a method to prevent manipulation of overlapped pixels by storing "taken" pixels in a sparse matrix, but the simple extra operation of the matrix lookup created extra overhead that actually slowed things down by about 10%.

So on the same token, calculating every pixel coordinate, sending them to a plugin to update an image file, waiting for the image file to be finished, then loading it, might be slower. Note that an image file will induce a heavier burden the larger it is, and Hologram allows you to scale the render up to the size of the screen.

Re: Hologram

February 24th, 2016, 9:06 pm
Bekarfel
   [186 posts]

Have you tried using a Ramdisk to store the file you're loading? I have one to test (up to 4 GB) if you don't. I also have an SSD, USB flash drives, and standard hard drives to provide benchmarking comparisons.
User avatar

Re: Hologram

March 1st, 2016, 1:57 am
killall-q
   [285 posts]

Bekarfel wrote:Have you tried using a Ramdisk to store the file you're loading? I have one to test (up to 4 GB) if you don't. I also have an SSD, USB flash drives, and standard hard drives to provide benchmarking comparisons.

Thanks, but based on the tests I've already done, I'm confident that storage device speed is not the limiting factor in load time.

The current version of Hologram virtually eliminates load time when there are enough meters loaded to display a model. After preloading, a 100k vertex (8 Mb) model loads in less than 2 seconds. Steps 5 and 7 have been isolated and are only executed when absolutely necessary. If the model file can load that fast, it's likely that reading a Meters.inc of similar size is also not limited by disk speed.

Re: Hologram

February 17th, 2017, 3:31 pm
ZolarV
   [4 posts]

killall-q wrote:You didn't misread. Because there's no sort of canvas, manipulating arbitrary individual pixels requires provisioning 1 meter per 1 pixel. If the desired result is more predictable, you could use gradients or roundlines, but manipulating those with !SetOption would actually be slower than simpler manipulations of thousands of simple meters.

Now if you want color and/or transparency... for the audio visualizer, I'm planning to "overload" each pixel by provisioning 6 or 12 1x1 meters per pixel, each in a different color, then using Show/Hide, which is orders of magnitude faster than !SetOption Blah SolidColor on fewer meters. 20-30k meters is a very reasonable budget as long as you're not wasting meters by overlapping them... which happens a lot in Hologram... hmm...

Speaking of DirectX, does Rainmeter having D2D means it uses the GPU?


I'm analyzing your lua scripts to see if i can't find a more efficient route for the mathematics to reduce total operations (reduce load time).
Did you already test all 3 coordinate systems? It might be easier to create a permanently saved matrix of relative points (x,y)to calculate spherical "quadrants" off of. There might be a few neat mathematical solutions that reduce operations. Creating a 1:1 correspondence of vertices to meters s probably the slowest and most inefficient solution. You might be able to calculate coordinates via gauss-sidel method.

Re: Hologram

February 17th, 2017, 4:12 pm
ZolarV
   [4 posts]

I just had another idea too. In order to remove the freezing aspect how about trying this:

1: add a new separate script program that performs the slow process, this program has a flag called IS_DONE
1.a: While running the process, IS_DONE returns false
1.b: When finished the slow process IS_DONE returns true
2: inside of your Hologram.lua check IS_DONE.
2.a: IF false send data to the script. and set flag IS_ACTIVE to false
2.b: IF true get data and set IS_ACTIVE to true

While IS_ACTIVE = false, set the window to a static window that only looks for an event "mouse hover"
On event mouse hover, check IS_DONE in second file.
IF IS_DONE = true then set IS_ACTIVE to TRUE
IF IS_DONE = false then do nothing.
While IS_ACTIVE = true, set the window to dynamic where it displays the mode.

Basically, this should create a separate process (from rainmeter) that performs the slow/freezing process. and will free up rainmeter to function while those processes happen.
While the second process is active the main rainmeter process/skin remains static. and once the second process is done the main rainmeter processs/skin becomes active to display the model.
User avatar

Re: Hologram

February 17th, 2017, 10:24 pm
killall-q
   [285 posts]

ZolarV, the math involved in setting up the model takes only a fraction of a second. There is barely any calculation done in model loading; much more complex calculations are done during rendering, and that happens fast enough that I used it to make an audio visualizer running at 40 frames a second.

I performed extensive tests, as I detailed previously, to find the bottleneck, and I found that the only substantial bottleneck is at the meter loading stage. It has a big-O complexity of O(n^2), which is classified as "horrible". This is something I cannot fix without delving into and altering the Rainmeter source.

I have isolated that time consuming process to be done only when necessary. So when you load a model with fewer vertices than the currently loaded model, or lower the edge interpolation setting, no new meters need to be loaded, and loading happens almost instantly.

On the freezing aspect, as Rainmeter is currently not multithreaded, putting some part of the skin in another skin would not help as all Rainmeter skins freeze when any one skin is busy.

Re: Hologram

February 18th, 2017, 8:47 am
ZolarV
   [4 posts]

killall-q wrote:ZolarV, the math involved in setting up the model takes only a fraction of a second. There is barely any calculation done in model loading; much more complex calculations are done during rendering, and that happens fast enough that I used it to make an audio visualizer running at 40 frames a second.

I performed extensive tests, as I detailed previously, to find the bottleneck, and I found that the only substantial bottleneck is at the meter loading stage. It has a big-O complexity of O(n^2), which is classified as "horrible". This is something I cannot fix without delving into and altering the Rainmeter source.

I have isolated that time consuming process to be done only when necessary. So when you load a model with fewer vertices than the currently loaded model, or lower the edge interpolation setting, no new meters need to be loaded, and loading happens almost instantly.

On the freezing aspect, as Rainmeter is currently not multithreaded, putting some part of the skin in another skin would not help as all Rainmeter skins freeze when any one skin is busy.


Ahh, i think i see what you are saying. the post creation loading of the meters into rainmeter causes slowness. not the actual computing done by the files.

2nd part: i see now that the 2nd thought wouldn't work either since it isnt anything to do with computations and all to do with the file::rainmeter interface. well that blows :P

Re: Hologram

February 18th, 2017, 9:16 pm
ZolarV
   [4 posts]

killall-q wrote:ZolarV, the math involved in setting up the model takes only a fraction of a second. There is barely any calculation done in model loading; much more complex calculations are done during rendering, and that happens fast enough that I used it to make an audio visualizer running at 40 frames a second.

I performed extensive tests, as I detailed previously, to find the bottleneck, and I found that the only substantial bottleneck is at the meter loading stage. It has a big-O complexity of O(n^2), which is classified as "horrible". This is something I cannot fix without delving into and altering the Rainmeter source.

I have isolated that time consuming process to be done only when necessary. So when you load a model with fewer vertices than the currently loaded model, or lower the edge interpolation setting, no new meters need to be loaded, and loading happens almost instantly.

On the freezing aspect, as Rainmeter is currently not multithreaded, putting some part of the skin in another skin would not help as all Rainmeter skins freeze when any one skin is busy.


What if you reduce the total number of meters needed to load. following the gauss-siedel or the jacobi method with a relative quadrant point;
You could have 1 meter per vertex and generate a new meter based upon a distance from the 1st meter and the relative spherical quarantine point.

between those two meters, you could use recursive calling to generate the points without creating new meters.

Basic idea is this: Have a set distance between 2 points (a,b) in space relative to a quadrant in spherical coordinates.
Instead of generating individual meters for all the points between meters (a, b), render the coordinate by calling the meter (a) and doing math to it. aka, (a+1)

List of meters for points between (a,e) = { b,c,d} translates into (a,e) = {a, a+math, (a+math)+math)}

Return to “Share Your Creations”



Who is online

Users browsing this forum: No registered users and 5 guests