Hologram

[killall-q]

I'm working on a point cloud audio visualizer, and I got distracted by this idea on the side that turned out to be easier.



Download from DeviantArt

Renders 3D models as wireframes.

View modes: vertices, edges, faces, edges+faces



Features

• Scale, rotate, and apply perspective to model
• Render vertices, edges, and/or faces
• Optional auto-rotation
• Automatically fits and centers model
• Uses no CPU while not being interacted with
• Supports STL and OBJ files

Explanation of 3D rendering algorithm


Usage

• Scroll to zoom.
• Scroll over or click arrows to adjust pitch/roll/yaw. Middle-click to reset to 0.
• Click cog or middle-click for settings.

Warning: I recommend turning off auto-rotation before loading a complex model.


See Also

• HoloFFT - 3D audio visualizer


Looking for 3D models to try? Thingiverse has a wide variety.

Comparison of point cloud (left) and wireframe (right) versions





CHANGELOG

[2022.12.01]
- Changed rendering method to use a shape meter, allowing rendering of edges and/or faces, and eliminating load times.
- The original point cloud version is available on GitHub. The other new features have been backported to it.
- Added STL file support.
- Added file browser.
- Added rotation value readouts.

[2016.03.21]
- Added left/right scroll anywhere to adjust yaw.
- Added middle mouse click to toggle settings.

[2016.03.09]
- Added 3rd axis of rotation, roll.
- Stabilized calibration of load time estimation algorithm.

[2016.03.01]
- Now gives "invalid file" error if selected file contains no vertices.

[2016.02.20]
- Added adjustable perspective.
- Added adjustable edge interpolation - uses additional points to render lines.
- Eliminated load time when loading a model with fewer points than are currently loaded.
- Added point preloading - load once, and don't experience load times again until loading a more complex model or using high edge interpolation settings.
- All actions that require reloading will prompt for confirmation.
- Point count is now displayed alongside load time estimate.
- Now prints model point count to log.

[2016.02.16]
- Added self-calibrating algorithm to estimate load times. Estimates may be inaccurate if calibrated on very small files.
- File load now scans file and provides a load time estimate, then prompts for load confirmation.
- Now prints load time to log.

[2016.02.15]
- Optimized rendering by precalculating sin/cos ψ/θ.
- Fixed custom color not taking effect after refresh.
- Fixed bug where setting file or color to blank would make their settings fields unclickable.

[eclectic-tech]

Impressive Work!

[killall-q]

Analysis of performance

This is probably the first Rainmeter skin to utilize 10,000+ meters at a time. At that point all methods of manipulation fall out of feasibility except for Lua Set/Show/Hide and group bangs. Surprisingly, Rainmeter doesn't even sneeze at pushing around <20,000 meters at a time, as long as they're not raster images. Those are the "low complexity" models that can be animated smoothly at 40 frames per second. I don't have the patience to load, say, Venus de Milo, but I wonder if there is an upper limit to the number of meters. I've tested 238k, pick your power of 2?


Album of test loads

The real bottleneck isn't in rendering, but loading. Everything's fine and dandy once it's all in RAM, but I suspect that loading 100k+ meters accounts for 99.9% of the load time because:

Even on the 238k test, the 8 megabyte Meters.inc was already generated and the vertex count saved after a couple seconds.

To clarify, these are the steps for loading something in Hologram:
1. Delete Meters.inc and refresh
2. Parse model file
3. Save vertex count to Settings.inc
4. Generate a meter for every vertex into Meters.inc <-- At least this much is done within 2 seconds
5. Refresh and load the newly generated meters
6. Parse model file
7. GetMeter() all the meters into Lua memory

That leaves only steps 5 and 7 to take 52 minutes. After that I did a test where I omitted the code to delete Meters.inc, and the load time was 88% longer. Thus, this is the division of computing time between loading meters and GetMeter:

Load + GetMeter = 100%
Load + Load + GetMeter = 188%
Therefore, Load takes 88% of the time and GetMeter takes 12% of the time.

I tried using print() to get timestamps but because Rainmeter is completely frozen when processing, they don't get into the log at the right times.

I've tested putting the model file on an SSD, putting Meters.inc on an SSD, and having everything including a portable install of Rainmeter on an SSD, and none of it makes a statistically significant difference.

Also, load time is proportional to the square of the number of meters:


I'm not expecting some change to Rainmeter to improve this situation as hardly anyone will see the benefit unless point clouds really catch on, but it would be fun to get some insight from someone familiar with the inner workings of Rainmeter as to cause of the square relationship.

...Well, except it would be nice to be able to SetMeter() directly to RAM instead of creating these huge text files then loading them back in. Sorry.

[dgrace]

I didn't quite follow you exactly - you created individual meters per vertex? I'm thinking a better way would be to implement a D3DMeter or something which would take in a vertex/index buffer as input and then let you apply transformations. (I'm not quite sure about how much of D3D is supported on the desktop though - very likely would be Win8+ specific)

Still I love the envelope-pushing! Makes me wonder if there's a way to pipe Rainmeter measure values into a vertex shader.

dave

[killall-q]

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?

[dgrace]

Well, I grant you it's an interesting approach. Let me know when you get something that looks good and I'll bet I can rewrite it as a custom D3DMeter that will run about 10000x faster.

As far as I know D2D doesn't get much benefit from the GPU, if any, unless there's some hardware-accelerated texture resizing or something. D3D vertex/pixel shaders are where the GPU comes into play. (Disclaimer, I'm not much of a graphics guy; other folks may well know more than I do)

dave

[killall-q]

I'm sure ye olde Voodoo card can outperform any CPU at 3D graphics. One is a hammer and the other is a steamroller.

I'm going to keep pushing the limits of CPU-based pseudo graphics because the desktop arena is sorely lacking in that regard and I don't believe that pretty graphics should only exist in games or other places where it's restricted to the window of one application.

However I'm afraid that GPU driven desktop widgets (the ultimate goal of the above paragraph) are a magical unicorn no one is interested in developing yet, at least on Windows. Linux has had GPU driven Compiz desktop effects for ages, but they're window transitions, not widgets.

It's been a few years since the Iron Man movies came out, I figured people should have caught the drift by now.

[~Faradey~]

Nice job

siiiick stuff

[moshi]

wow. i'm impressed.

gear unicode:
http://www.fileformat.info/info/unicode/char/2699/index.htm

[dgrace]

What if you had a custom plugin that would render the 3d to a .png? Then you could pipe it to an image meter. That would avoid the overhead of one meter/vertex and let you do all the 3d transforms in one place.

dave