Are you making a demo? Don't forget your splines, they are the cool thing now...
Lifeforce
Nematomorpha
The Seeker
Atrium
Scarecrow
Invoke
The "progressively appearing" geometry trick is also commonly used to draw them:
Route 1066
Falling down
Media error
Tactical battle loop
Cubes seems to be cool only if you instance a crazy number of them now:
Debris
Momentum
Another cool trend: 2d metaballs
Nucleophile
Incognito (near the end, this one features ribbons too)
Lifeforce
Nematomorpha
The Seeker
Atrium
Scarecrow
Invoke
The "progressively appearing" geometry trick is also commonly used to draw them:
Route 1066
Falling down
Media error
Tactical battle loop
Cubes seems to be cool only if you instance a crazy number of them now:
Debris
Momentum
Another cool trend: 2d metaballs
Nucleophile
Incognito (near the end, this one features ribbons too)
8 comments:
I think we started the popularisation of "ribbons" in the demoscene in http://www.pouet.net/prod.php?which=14110 back in 2004.
Now it's almost become a tradition for us to use them - I used them in http://www.pouet.net/prod.php?which=51125, partly to annoy people who complained about how much we used the technique, and partly because growing glowing lines just undeniably looks good.
Our artists do most of the growing stuff nowadays (in the later fairlight productions) with meshes and no code required - it's now a design tool not an "effect", and a good way of showing "flow" (a technique commonly used in motiongraphics).
It leaves us coders free to do some more interesting fx instead. :) (like smokeboxes or something)
Yes I've noticed that, sorry if I didn't include those demos to the list, actually it wasn't meant to be a complete one, I've just quickly chosen some prods.
Actually I love all the latest fairlight productions, you're doing great on c64 too...
The "smokebox" was nice but I would like to see it integrated in the demo, rather than the old-school "see-my-cool-effect" style (because anyway we saw that cool effect in the nvidia demo before right... ;D)... I'm waiting for someone to do in realtime the shining's blood-from-the-elevator scene... :D
The growing stuff is nice, incredibly simple and of so much effect...
Do you have lots of tools for demo-making and previewing effects, integrated with DCC tools etc, or you go the mostly-all-procedural way (like ASD seems to be doing)?
haha, the thing with the smoke box is : a) it was totally calculated and raytrace lit on 1 core of the cpu (which as you know is like 10% the flops of that 8800 that nvidia used for theirs) so i hate to compare it to nvidia's :) and b) the reason everyone puts their 3d smoke in a box is that the res is so limited :) theres not that much you can do with it, except put it in a box. we're doing things with SPH now, it gives more freedom. and that means we can integrate things a lot better. oh yea, and c) we added the effect to the demo about 12 hours before the deadline.. :)
for making demos we have our own tools, the hardcoding approach is far too painful :) . we have a demo tool which is a bit like eyeon's fusion - it has a node graph, timeline, animation curve editing and so on. we use lightwave for modelling and e.g. character animation (and we load lightwave's native file formats), and make the rest in the demo tool, coding new fx whenever needed. the tool just cuts out the pain of fixing cameras, timing, placement of objects etc which is so annoying to do in code.
its very flexible - we used the same one for all the fairlight and ukscene allstars demos, the recent fairlight 64k (panic room), and recent issues of the zine diskmag. it has a plugin architecture, so we just make the new fx plugin (really a dll), and it is found and used by the tool automatically.
the thing is, quite a lot of different artists are using our tools, and they aren't being paid for it or forced to do it. if they think it sucks, they won't use it, or they certainly wont make anything good with it. so we had to make it good enough.
with games ive worked on the tools have often been much worse, because you can just say "tough, you have to use it anyway" - we cant do that. :)
Yes I think that SPH are the way to go on the CPU, eulerian solvers are very nice on streaming architectures like the GPU, I'm looking forward for your next demo then :)
A lot of people are doing demos using graph-based tools or timeline-based ones.
Even if that lets the artists work without the need of having continuously to iterate with coders, don't you think that for demos this is limiting? I think that your demos show a good balance of artist-authored content with procedural elements, but still I think that going procedural enables the artists to create stuff that it's impossible with standard authoring packages.
I would like to see artists that learn to code and coder that learn not to use CGA-colors.
What do you think of procedural artists? Do you follow that kind of scene too? Like stuff done by proce55ing artists, vvvv (if you don't know that one, you should have a look, it's graph-based, but low-level enough to let you modify GPU streams etc) etc? Or stuff like: http://www.generatorx.no
i've only recently discovered the excellent communities of generative artists on vimeo and flickr. very cool stuff coming out of processing, vvvv, etc.
ye proce55ing is everywhere, there are links to the various flickr, delicious, etc etc etc groups on the homepage. The ruby version of it is one step closer to what I would like in such a language! Also there are a few python based ones, on osX, that are worth investigating
cubes are the new cubes :)
http://pouet.net/prod.php?which=51448
http://pouet.net/prod.php?which=51449
Yes, I've seen texas, the nvscene'08 intro, it's really really good! BUT in the article I wrote that cubes are ok if you instance a crazy number of them, and this is what texas does, so it's still ok :D
Post a Comment