cug About | News | Screenshots | Download | Plans | FAQ | Contact

Cug is an equation plotter with a heavy emphasis on beautiful rendering--it can be considered a simple openGL modeler parameterized by mathematical equations. Extensive controls allow for real-time modification of lighting, coloring, texturing, fog, and a few other aspects. Rotation, panning, and zooming are easily controlled with the mouse. An off-screen rendering target allows for generation of large images. The excellent gtkmm and gtkglextmm libraries provide the interface.

Current features: New in 0.0.1:

April 07 2004. 0.0.1 released; list of features is visible in the immediately preceding area. Automatic build configuration is provided by pmk, rather than autoconf/automake.

I've deleted the news log because it was pointless. Anyway my laptop hard drive ate itself a few days ago (head crash), so that slowed me down a little bit. Please download cug and check out my future plans below..


[0.0.1] New features going into the 0.0.1 release can be seen here. I was lame and used the default equation again. The interface has been cleaned up some, but I hid it in this shot since I wanted to highlight the render..
[0.0.1] An aesthetically dismal shot presenting some of the new stuff. The ray of yellow hexagonal donuts appears when the light source is rotated. I made this shot in a hurry however the results can be rather pleasing when done in real life. The texture used is of course our favorite Mr. Alan Cox.
[0.0.0] A multitude of coloring equations made this one. I used a standard trick to clean up solid transparency--I used an equation to increase the level of alpha towards the bottom. A constant alpha or evenly fluctuating alpha usually looks quite miserable.
[0.0.0] Here's a rather plain looking image showing how equation based coloring on the wireframe can be used to highlight peaks. I'm also showing the fact that there is some basic error reporting for improper input. I'll make more informative messages later--point is you won't blow anything up by entering crap input (if you do find a parser error, please email me!!).
[0.0.0] A very simple completely fullscreen shot with the prefs and bottom bar hidden (hit 'h' to do that, or click the hide button). The prettiest images I've made (not here, I'd be a loser to use only the best material for examples) usually have highly transparent solid models, and accentuate the wireframe..
[0.0.0] Slightly turbulent (like the background image within). Shows off usage of an equation to control alpha transparency, getting a rather intense effect. Note that having transparency on the wireframe and solid is currently kinda slow.. I know good ways to optimize it but have been too lazy thus far. Gimme a sec.
[0.0.0] Simple coloration schemes can look great.

version 0.0.1a, 45640 bytes

up until 0.1.0: After that:
(frequently underwhelming chicanery)

Yeah.. the interface kinda 'pops' when I zoom in and out. Is this because I'm smarter than you?
Excellent deduction. The mesh vertices are cached, and as the zoom crosses a logarithmic threshold the points are recomputed at a new distance. Otherwise zoom in/out simply scales the current model
Actually that's not what I was talking about. Certain structures change quite drastically, which is most definitely an error
Well if you want to define the error as the zoom in/out not being 100% honest, then well I guess so. The truth of the matter is that the mesh is a discrete sampling of a continuous function; there is all the probability in the universe that at certain resolutions all sorts of detail is being missed, and then changing the subdivision picks up all sorts of magical crap.

At least, it's nice like that out in the forest where I live.
I can't see my model. What gives?
Maybe it's out of the view? If you think you found a rendering glitch, please tell me.
Expose events seem to be laggy...
Redraws are asynchronous; the event loop checks to see if a redraw flag is set and only draws then. It is very possible for all of the universes expose events to fall within the loop interval. It seems smooth when you rotate/zoom/translate, and when you tweak from the gui, but maybe resizing is funky. Luckily this saves some people's asses since video card drivers can suck--my ATI likes to crap on itself when redrawing too much (eh, if I handled expose synchronously).
Why didn't you use [insert whatever you wish] equation parsing package?
Most importantly to me, I really enjoyed writing my own parser. Most importantly to you, it's designed to be intimidatingly quick (notice that you can set an equation for each color channel, calculated per vertex, and have it be done in real time). It's nicely reusable and easy to use (as you can guess from my reuse of it in the coloring).
The interface sucks. The fullscreen handling of prefs is silly (just use a dialog!).
I changed this in 0.0.1, the new prefs handling rules.
I don't see 100% processor utilization. Your program is poorly written.
I use glib's internal scheduler to handle my loop. I could get things smoother if I rolled my own less general/more tight one.. I may do this.
I looked at your code and it's.. strange. Definitely inconsistent, if anything.
This is my first c++ project, my first openGL project, and my first freely available program. I'm using it as a massive test bed, even for things like internal structure, parameter order, variable naming, indentation, etc. It does change quite drastically, I'm aware. It's intentional.

I'm very interested to hear what people think, what people want. "Don't write webpages after staying up for 24 hours" I do not need to hear. "The program sucks" I do need to hear. Remove capitalized crap to parse my email address: maSPAMtus at telMAPSgarsky dot com (should be obvious, I'm Matus Telgarsky)