algorithmic modeling for Rhino
Testing the limits of the Eto.Drawing namespace for faux and proper 3D colour pickers. It's *smooth*. The main speed improvement over System.Drawing (Grasshopper 1.0) is that textures and bitmaps render waaay faster, allowing me to render UI pixels to off-screen bitmaps and then draw them to the screen.
The picker colours are all computed on the main thread in 16x16 pixels, which is fast enough for a high frame-rate, and then cached to 64x64 pixel images in background threads.
The sphere is a colour space of my own design. It's similar to HSL but uses a more advanced luminance metric, thus each latitude should have the same greyscale value. But that depends partly on monitor calibration, so it's impossible to get it right for everyone.
Tags:
Comment
Leave it to an architect/coder to make 3-dimensional color pickers. Great stuff!
Very nice David. The sphere is great. Is there a noticeable difference in the calculation frame-rate? For example, I've noticed that in GH1 that the frame rate is tied to the graphics UI thread (which makes sense). So, if you have tons of components (and text panels) on the screen, the solution cycle will slow down. I can get approx 30fps, but if I scale down the Rhino viewport and GH window, I can get closer to 60fps (since it's not having to draw as much stuff on the screen). So, is there a significant boost in frame rate frequency using this new drawing routine?
I'm already a big fan of the colour wheel. But a colour sphere - that's literally the next dimension!
Great news ;) Thanks!
@Thibault, GH2 (or at least the canvasses) should be fully skinnable, so if you want to dim the palette that will be possible. In fact a skin editor is the first serious piece of functioning UI I want to write, so you can see why I'd need colour pickers :)
PICKY REPORT (just pushing it to perfection :P): I saw some glitch between the static colour sphere and when you move it, was it caused by video compression or by the redrawing algorithm?
It's because I need to render a low quality preview during dynamic updates. So I only budget for 16x16 pixels while the sphere is rotating (or while the cube planes are moving), but then calculate a 64x64 high quality image when the motion stops. I might still make it better, but I doubt it'll always look really clean. Eto simply doesn't have a 3D drawing api so what you're seeing here is form of real-time raytracing.
Eto doesn't stand for anything as far as I know. Curtis just liked the sound of it.
Looks great David!
Just something that comes to my mind when I was looking at the video: it would be great to include some support in the UI for color sets reducing eye strain, including "dark" themes if possible. Not that GH colors are bad, but I guess it would make sense, GH being a pure .Net VPL afterall, giving it features of a traditional IDE sounds natural to me (and the colors of these new GH components seem to go towards this direction).
And a little question (probably nonsense) what "Eto." states for?
xD...is people actually emailing you asking for a beta??? :S
The UI design is very neat :)
PICKY REPORT (just pushing it to perfection :P): I saw some glitch between the static colour sphere and when you move it, was it caused by video compression or by the redrawing algorithm?
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by
You need to be a member of Grasshopper to add comments!