It is currently June 14th, 2024, 6:20 pm

Hologram

Media controls, music players, video and animated visualizers
User avatar
killall-q
Posts: 305
Joined: August 14th, 2009, 8:04 am

Re: Hologram

Post by killall-q »

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.
Bekarfel
Posts: 216
Joined: May 16th, 2012, 5:38 am

Re: Hologram

Post by Bekarfel »

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.
moshi wrote:there are many Rainmeter skins that aren't really useful, so let's add another one.
jsmorley wrote:I have good news and bad news.
First the bad news. [...] We would be happy to have this happen and would love to work with anyone who is feeling ambitious.
Now the good news.
I lied, there isn't any good news...
User avatar
killall-q
Posts: 305
Joined: August 14th, 2009, 8:04 am

Re: Hologram

Post by killall-q »

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.
ZolarV
Posts: 4
Joined: February 17th, 2017, 3:24 pm

Re: Hologram

Post by ZolarV »

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.
ZolarV
Posts: 4
Joined: February 17th, 2017, 3:24 pm

Re: Hologram

Post by ZolarV »

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
killall-q
Posts: 305
Joined: August 14th, 2009, 8:04 am

Re: Hologram

Post by killall-q »

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.
ZolarV
Posts: 4
Joined: February 17th, 2017, 3:24 pm

Re: Hologram

Post by ZolarV »

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
ZolarV
Posts: 4
Joined: February 17th, 2017, 3:24 pm

Re: Hologram

Post by ZolarV »

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)}
User avatar
killall-q
Posts: 305
Joined: August 14th, 2009, 8:04 am

Re: Hologram

Post by killall-q »

I've overhauled Hologram with a new rendering method, using a shape meter to draw an arbitrary number of triangles. See the edited original post for comparisons between the original point cloud renderer and the new wireframe renderer.

Using a single meter for rendering also eliminates load times. However, because this new method involves rasterization, (re)draws are much slower than the original point cloud method. Still, rendering will be less than 30 seconds even for very complex models, compared to the minutes or hours it took the point cloud version to load points.

To make user interaction smoother, if the last render took longer than 0.5 seconds, then whenever the user interacts with the skin, Hologram will automatically replace the model with a low poly stand-in. When you are done adjusting settings, click anywhere to start rendering.

I've also added STL file support (both ASCII and binary formats) and a file/folder browser. No more copy-pasting in file paths!

The new QOL features have been backported to the point cloud version, which can be downloaded on GitHub.
User avatar
ikarus1969
Posts: 575
Joined: February 28th, 2011, 3:20 pm
Location: Vienna, Austria

Re: Hologram

Post by ikarus1969 »

A crazy project. But crazy in the best sense of what is possible (with rainmeter). Thank you!