The "motion blur" in these scenes is not actually motion blur... it's the same thing as pixel memory (remember those old phosphorous screens and my favorite xscreensaver).
Sort of, it's actually something that SGI started calling an Accumulation Buffer many years before 3DFX ever existed. How does it work? Simple, enable alpha blending, don't clear screen buffer memory on each frame, and render all your polys with alpha set to whatever level you want (depending on the effect you want..).
Here's a simple (!) demo that I wrote for a 3DFX-sponsored demo competition, got 5th place, and did motion blur years before 3DFX hyped T-buffering. Included is all 200-lines of source code.. d:^)
Any 3D chipset that supports alpha channels can do motion blur without any significant hit to framerate or CPU overhead. In fact, the Atari and Amiga demo scenes were doing this using bitplane tricks.
I doubt if any of you ever used a General Magic operating system. I believe their OS was called Magic Cap. It was the OS of early, pre-Pilot PDAs such as the Sony MagicLink and I believe the Motorola Envoy. Very similar to Bob,
I owned a Sony Magic Link (still have it) as well as many of the few accessories and software packages for it. It was a pretty cool device for it's time, but there was a good reason that it failed. Magic Cap was unbearably slow and, for all it's icons-up-the-ass cutesiness and so-called simplicity, it was a pain in the ass to use. It also made the assumption that all users are complete morons who shouldn't have any control over how their files are stored.
Often times, you'd be sitting waiting for minutes while Magic Crap performs garbage collection, eating up valuable battery time, not to mention the fact that getting to some particular tool or app often required jumping to different scenes, then maneuvering left/right to find a particular building or door.
I was looking forward to an update that would fix many of the significant problems with the OS, but it never came. They originally had planned to include an app building tool, but that never came either. Instead, they tried to market Magic Crap for Windows (Why???).
Now Hertzfeld and Co. want to do the same thing for Linux [http://www.eazel.com/]. From what I've seen of it, it looks like they may actually have some good ideas about how to make Linux accessible to general users. Personally, I think KDE 2.0 is just fine.
Sorry, but these packages do not produce motion that looks like real cloth in anything other than very restricted situations....
Like draping over simple objects.
The technology is a long way from producing convincing simulations automatically.
Actually, you can achieve amazingly realistic cloth simulation in just about all situations with Maya Cloth, however it usually requires some amount of setup work. Maya Cloth is fully capable of simulating realistic clothing that conforms to the 'skin' of a deformable object (or set of overlapping objects) which forms your character.
Additionally, there are numerous cloth properties that you can adjust to simulate just about any type of material like denim, silk, cotton, leather, paper, etc and you can apply different dynamic forces such as wind, gravity, magnetic forces, and so on.
Setup is certainly not "automatic" as it requires letting the clothing 'shrink' onto the body of the character and manually adjusting collision and tesselation factors to achieve realistic cloth simulation and reduce calculation time.
Once this is done, however, you can pretty much concentrate on animating your character and Maya Cloth does all the rest. A good example of Maya Cloth in action is the clothing on the main character in Stuart Little.
I am wondering why the IESDK doesn't include any 2D graphic libraries (such as SDL)... since not all games are 3D;)
I would suggest that the reason might be due to the fact that OpenGL is not necessary a 3D API but a graphics library with operations that can operate in either 2D or 3D.
Glide is actually a very good API. It's fairly clean and relatively easy to learn if you have used OpenGL, especially considering that the API is fairly low-level and close to the hardware functioning of the chipset.
It lacks the high-level features of OpenGL such as doing matrix transforms, display lists, primitives, texture coordinate generation, etc. Glide was designed for game developers, who generally would prefer to implement these functions themselves, anyway. Since Glide was chipset specific and offered a lot of low-level control, you could come up cool effects with a bit of hacking. What 3DFX now hypes as T-Buffering was easily possible on the Voodoo1 chipset with Glide 1.1. With a couple of lines of code you could get fairly effective full-scene anti-aliasing and motion blur.
Most companies were developing their own APIs in the mid 90's so it was natural that 3DFX would do it as well. Rendition (RIP), 3DFX's early main competitor, had their own called Redline and NVIDIA's first attempt, the Edge3D, had an API that was kept away from anyone but licensed developers. Sidenote: NVIDIA used to imply that the Edge3D could render quadratic surfaces in hardware - I wonder what ever happened to that feature. d:^)
It probably could be called Maya Unlimited (text mode edition).
Assuming that this package is equivalent to batch rendering on the SGI platform, this appears to be a semi-complete port of the full Maya package. While Renderman and MentalRay have been available on the Linux platform for some time, there is a big difference between how these work and how Maya Batch Render works.
I'm assuming that Maya Batch Render for Linux works the same way as IRIX. I only use Maya on Onyx2 and O2 hardware, so I may be wrong about this....
First of all, Renderman and MentalRay are essentially stand-alone programs that read in a generic scene geometry/lighting/shader information for each frame. They do not know how to animate a scene on their own. Neither package is necessarily tied to a particular modeler. MentalRay is available for Softimage and 3DMax, and Renderman can work with numerous modeling apps.
Maya Batch Rendering, on the other hand, is very modeler specific. In fact, it _IS_ the modeler. Let me explain;
Part of the elegance of Maya is the fact that much of it is implemented in the MEL scripting language and is open architecture. You can change almost any behavior of the program at run-time merely by editing the scripting code. (think Emacs!)
In addition, every action the user takes within Maya is interpreted as a piece of MEL code. When you save a scene in Maya, it is saving a MEL script that includes all the discrete steps to rebuild the scene, such as creating primitives, deforming objects, setting up dynamics simulations, storing key information, motion paths, creating shader networks, etc.
The Maya Batch Renderer is essentially a non-interactive version of Maya. It executes a file containing MEL scripting commands roughly equivalent to GUI operations to build up a scene internally, then renders a set of frames calculating any (non-precached) animation data along the way.
Incidentally, Renderman and Mentalray are generally considered superior to Maya's rendering facility. A lot of high-end CGI work is only modeled and animated in Maya, but rendered in Renderman. Paint Effects in Maya 2.5 can do quite a few things that no other rendering package can even approach, however.
By the way, Lightflow is another renderer that is currently available for Linux that produces some amazing images, albeit very slowly. There is a Maya interface being developed for this package so it looks promising.
Come on guys, this is about Sibelius a music notation program. It was brought to you by the Finn brothers, the guys that programmed a RISC chip in Assembler. The article is just some free promotion for Sibelius software
Sibelius does NOT destill or mimic any musical style. If anything, it mimics the musical style of a particular programmer at Sibelius.
Mimicking and destilling style is a subject of ongoing research. You could check out the work by Douglas Cope -- who destilled stylistic features of composers. You can also head over to...
Actually, if you had read the article, it appears that what they are trying to do is mimic the live performance of a real musician rather than the style of a composer - Totally Different.
I could care less about algorithmic music since most of it sounds like shit, anyway, but to use a computer to recreate idiosyncracies of a particular instrument or performer is actually quite practical.
For instance, guitar is an instrument that is full of idiosyncracies. Given a sequence of notes, an algorithm would have some rough idea of the physical layout of the guitar fretboard, string tunings, physical limitations of the human hand, etc. The program would then determine, iven these notes, how a guitarist might actually play them. For instance, where would the guitarist need to slide to a fret position (fret noise), where notes might be picked or hammered (attack), which string is in closest physical proximity (intonation, tone, whatever), and there's a whole shitload of other possibilities.
Slashdot Mirror
Sort of, it's actually something that SGI started calling an Accumulation Buffer many years before 3DFX ever existed. How does it work? Simple, enable alpha blending, don't clear screen buffer memory on each frame, and render all your polys with alpha set to whatever level you want (depending on the effect you want..).
Here's a simple (!) demo that I wrote for a 3DFX-sponsored demo competition, got 5th place, and did motion blur years before 3DFX hyped T-buffering. Included is all 200-lines of source code.. d:^)
http://www.concentric.net/~Psteffen/savers3DFX/
Any 3D chipset that supports alpha channels can do motion blur without any significant hit to framerate or CPU overhead. In fact, the Atari and Amiga demo scenes were doing this using bitplane tricks.
STratoHAKster
I owned a Sony Magic Link (still have it) as well as many of the few accessories and software packages for it. It was a pretty cool device for it's time, but there was a good reason that it failed. Magic Cap was unbearably slow and, for all it's icons-up-the-ass cutesiness and so-called simplicity, it was a pain in the ass to use. It also made the assumption that all users are complete morons who shouldn't have any control over how their files are stored.
Often times, you'd be sitting waiting for minutes while Magic Crap performs garbage collection, eating up valuable battery time, not to mention the fact that getting to some particular tool or app often required jumping to different scenes, then maneuvering left/right to find a particular building or door.
I was looking forward to an update that would fix many of the significant problems with the OS, but it never came. They originally had planned to include an app building tool, but that never came either. Instead, they tried to market Magic Crap for Windows (Why???).
Now Hertzfeld and Co. want to do the same thing for Linux [ http://www.eazel.com/ ]. From what I've seen of it, it looks like they may actually have some good ideas about how to make Linux accessible to general users. Personally, I think KDE 2.0 is just fine.
STratoHAKster
Actually, you can achieve amazingly realistic cloth simulation in just about all situations with Maya Cloth, however it usually requires some amount of setup work. Maya Cloth is fully capable of simulating realistic clothing that conforms to the 'skin' of a deformable object (or set of overlapping objects) which forms your character.
Additionally, there are numerous cloth properties that you can adjust to simulate just about any type of material like denim, silk, cotton, leather, paper, etc and you can apply different dynamic forces such as wind, gravity, magnetic forces, and so on.
Setup is certainly not "automatic" as it requires letting the clothing 'shrink' onto the body of the character and manually adjusting collision and tesselation factors to achieve realistic cloth simulation and reduce calculation time.
Once this is done, however, you can pretty much concentrate on animating your character and Maya Cloth does all the rest. A good example of Maya Cloth in action is the clothing on the main character in Stuart Little.
Paul
I would suggest that the reason might be due to the fact that OpenGL is not necessary a 3D API but a graphics library with operations that can operate in either 2D or 3D.
Glide was obviously based on the simplicity of OpenGL. It's designer was Brian Hook who worked at id Software on Quake2, and I think previously worked at SGI on the first optimized (read: non-Microsoft) OpenGL software implementation for Windows.
It lacks the high-level features of OpenGL such as doing matrix transforms, display lists, primitives, texture coordinate generation, etc. Glide was designed for game developers, who generally would prefer to implement these functions themselves, anyway. Since Glide was chipset specific and offered a lot of low-level control, you could come up cool effects with a bit of hacking. What 3DFX now hypes as T-Buffering was easily possible on the Voodoo1 chipset with Glide 1.1. With a couple of lines of code you could get fairly effective full-scene anti-aliasing and motion blur.
Most companies were developing their own APIs in the mid 90's so it was natural that 3DFX would do it as well. Rendition (RIP), 3DFX's early main competitor, had their own called Redline and NVIDIA's first attempt, the Edge3D, had an API that was kept away from anyone but licensed developers. Sidenote: NVIDIA used to imply that the Edge3D could render quadratic surfaces in hardware - I wonder what ever happened to that feature. d:^)
Paul
It probably could be called Maya Unlimited (text mode edition).
Assuming that this package is equivalent to batch rendering on the SGI platform, this appears to be a semi-complete port of the full Maya package. While Renderman and MentalRay have been available on the Linux platform for some time, there is a big difference between how these work and how Maya Batch Render works.
I'm assuming that Maya Batch Render for Linux works the same way as IRIX. I only use Maya on Onyx2 and O2 hardware, so I may be wrong about this....
First of all, Renderman and MentalRay are essentially stand-alone programs that read in a generic scene geometry/lighting/shader information for each frame. They do not know how to animate a scene on their own. Neither package is necessarily tied to a particular modeler. MentalRay is available for Softimage and 3DMax, and Renderman can work with numerous modeling apps.
Maya Batch Rendering, on the other hand, is very modeler specific. In fact, it _IS_ the modeler. Let me explain;
Part of the elegance of Maya is the fact that much of it is implemented in the MEL scripting language and is open architecture. You can change almost any behavior of the program at run-time merely by editing the scripting code. (think Emacs!)
In addition, every action the user takes within Maya is interpreted as a piece of MEL code. When you save a scene in Maya, it is saving a MEL script that includes all the discrete steps to rebuild the scene, such as creating primitives, deforming objects, setting up dynamics simulations, storing key information, motion paths, creating shader networks, etc.
The Maya Batch Renderer is essentially a non-interactive version of Maya. It executes a file containing MEL scripting commands roughly equivalent to GUI operations to build up a scene internally, then renders a set of frames calculating any (non-precached) animation data along the way.
Incidentally, Renderman and Mentalray are generally considered superior to Maya's rendering facility. A lot of high-end CGI work is only modeled and animated in Maya, but rendered in Renderman. Paint Effects in Maya 2.5 can do quite a few things that no other rendering package can even approach, however.
By the way, Lightflow is another renderer that is currently available for Linux that produces some amazing images, albeit very slowly. There is a Maya interface being developed for this package so it looks promising.
Actually, if you had read the article, it appears that what they are trying to do is mimic the live performance of a real musician rather than the style of a composer - Totally Different.
I could care less about algorithmic music since most of it sounds like shit, anyway, but to use a computer to recreate idiosyncracies of a particular instrument or performer is actually quite practical.
For instance, guitar is an instrument that is full of idiosyncracies. Given a sequence of notes, an algorithm would have some rough idea of the physical layout of the guitar fretboard, string tunings, physical limitations of the human hand, etc. The program would then determine, iven these notes, how a guitarist might actually play them. For instance, where would the guitarist need to slide to a fret position (fret noise), where notes might be picked or hammered (attack), which string is in closest physical proximity (intonation, tone, whatever), and there's a whole shitload of other possibilities.
STratoHAKster
ftp://ftp.sgi.com/sgi/fsn/
Also, here's a screenshot.