pouët.net

Speaking of 'showing stuff from a distance to get a sense of scale', there's a problem with that. Sometimes it works, and you get a sense of scale, but sometimes it just looks like a miniature model of something big. Can anyone shed light on why, and how you can keep the sense of scale?

psonice: i'm not a 3D designer at all, but in photography, that is achieved by either lowering the depth of field (effect that can be easily achieved with today's hardware), and/or using something on a first plane and have something (a floor or whatever) extend from the first plane onto the background. That's the most common way to do it with unrecognizable objects in photography... guess it should not be much different when doing 3D scenes (much less when it is animated).

Putting something recognizable (of a recognizable size) helps inconsciously (the mind assumes a mountain is big, and clouds are big, and a tree is of a defined size), but it's not really needed

I had to do alot of tricks to show the scale in metamorphosis, that is changing all the time (from small to big to small again). One that I found worked quite well was the parallax mapped walking figures or other recognizable figures (airplanes, statues, balloons, the city).

psonice: Yeah, it's tricky, and with demos, details on stuff in the background is sometimes "destroyed" by mipmapping I guess. Again, if you make sure to add tiny details to the surface of objects (either use a very high resolution texture or use a shader to add details to it in real-time) it will usually work out nice. Also; it works better with objects that are designed to resemple something that the mind already recognizes. If it is abstract stuff, then it can be hard to achieve a good sense of scale.

navis: Yes, that works quite nicely.

why? do you know why navis/asd ?

I think that also a question of speed, you don't turn/move around big objects so quickly.

Oh, and I remembered something else as well (since camera-moves have been discussed already): the speed of the movement of objects and/or camera is sort of essential when trying to achieve a sense of scale. I often see this in demos: something that is ment to be "huge", but the camera just zooms fast across. If you have a big, big object.. move it slowly! Then move the smaller framing-objects fast. Instant sense of scale.

gotcha :]

hitchhikr: Gah, you were faster. :)

Talking about camera paths...
@rainmaker: partly true. In seeker I had a rough idea and used a placeholder camera path for about 4 weeks. Then I lost control over the animated objects and switched to an observer camera following the action from some distance. One day before the deadline I redid the complete camera path to select the nice spots and hide upvector glitches in the spline wiggler. The cut in the middle was -- should i say -- too tempting.

For other productions I normally do *lots* of camera paths. Maybe 5 to 10 times more than I need. Then I actually do NLE: selecting fractions, change speed, think about cuts. Although this does not lead to seamless asd flow I prefer it nevertheless.

What gloom said:
Another thing I try to avoid is quick camera moves. Letting the camera fly through the scene will make objects look smaller. In real movies you scarcely see this "fly cameras" can if so I think they are for increasing the speed of small moving objects (like spidermen and spacecrafts flying around).

What about such topics as...
- Change in the speed of demos (varying speed of editing and camera?)
- Colors?
- Image overlays / 2d graphics

Change in the speed needs to be accompanied by change in speed in the visuals. Sidenote: this is why most demos with drum'n'bass tracks doesn't work very well. No real contrast in the dynamics of the track doesn't open up for real contrast in the visuals, and henche; the demo becomes boring. I pretty much hate demos where the camera and objects in the scene move at constant speeds.

Colors are aaalways tricky. A little tip that Kusma once gave me was to include a little bit of color in textures that are going to be blended. Like; not 0,0,0 for black, but 5,5,20. Such small things add heaps to a scene. Complementary colors are always a good tip - so is playing with the saturation. Just look at the Conspiracy-demos that Zoom has had his hands on. I think the trick in "Chaos Theory" was to render the scene in black and white and then add colors through the use of a gradient to the whole scene.

Image overlays is always tricky. Many people add them (present company included :) but it doesn't always work. Most of times, I feel artificially distanced from what is going on on screen. Like in the FLT+TBL demo for the Intel Demo Competition this year.. it worked in some scenes but not in others.

what we do is have the demo as a function of time (ofcourse). Time is calculated through Time+=DeltaT. Now, DeltaT is also a function of time !:

// DeltaT coming from the system
DeltaT*=1-(0.5*delay_factor(Time));

this way we can delay the demo at will without changing anything else (hard timings e.g. if time>10 do this and that). Can also be used for matrix-type camera speedups (the whole world will speed up too as a result).

I usually add 'spikes' of speeding up/down to compensate for loss of timing or for effect:

DeltaT*=1+(0.1*sin(PI*max (0,min (1, (Time)*0.5))));

This is actually something that big budget hollywood movies manage to fuck up sometimes. You have huge CGI battles or whatnot, but 'shot' with a camera flying around that has no connection to the realities of camera crane operation, helicopter cameras etc. At least for me those tend to screw up the movie experience.

Same goes for demos. If the camera is moving without any 'physical' limitations, it feels detached from the world.

Shouldn't the time be something... that changes in a constant way? Non relative? :D
That's the kind of thing that only makes sense if you're the one coding it :P

xernobyl: Why? Then you end up with a linear and dull experience, with no dips and peaks. No contrast.

i roger-roger ra in this sense.. all this quasi-intellectual subjective mumbo-jumbo has nothing to do with making demos per se. there are no rules in art, if you follow your OWN creativity :)

..and there it is; the obligatory "OMG! MAKE WHAT YOU WANT! NO RULES!!!111"-comment. :)

Navis: a couple of independent timedeltas and (more or less) linear times are really useful for some things. Speeding up parts of a scene, or pausing it, but letting the camera still move etc etc. (did that in the ballet dancer at least)

i'll try and put into words what i dislike about this subject.

the scene say 15-20 years ago was clearly generally clueless about "direction" or "design". over time we've improved. but for the most part its not our overall strength (that would be "making things that look cool/clever in realtime") - most of us are not budding tarantinos here. we learned to code and make music and pixel/model stuff instead.
as such, most of us (demo makers as well as watchers) have picked up ideas on what makes "good direction" as a side effect - often from what others consider to be good direction in a demo, and often by picking things from other demos which are considered to be good direction. this has lead to the viewpoint as to what makes "good direction" in the scene a very narrow one.
its much like the argument that a lot of people consider that the only things which are "real demos" are demos which have a load of glowing blobs and cubes in it. or that mandelbrot zoomers and realtime raytracing are still the greatest achievements one can possibly reach when it comes to demo fx. i.e. the demoscene tends to be so introverted that it eats itself.

the problem is, we're no experts here, generally speaking, so we've decided what's good based on some very safe and limited principles. if you only have one long part, you cant be inconsistent. if you only use about 3 colours, you cant have a bad colour scheme. if you slow it down on the slow parts of the music and speed it up on the fast parts, and do a couple of direct syncs, it cant not fit the musicl. that's demoscene direction. it's safe. it's efficient. it's about "not fucking up". it's basically been taken from a few great demos which did have good direction and followed that pattern - then copypasted by many others.

what this has lead to is a certain style of production - like the still intel demo - being lauded for it's great direction, when it's imho just a good example of the demoscene's view of what good direction is. it's consistent (i.e. one long scene), it's got good colours (i.e. a limited colour palette), it has "good camera movements" and it attempts to tell a story but in an abstract way (i.e. it follows a ribbon).
we've seen trends like this before. its like in the mid 90s on amiga, when "design" in demos was basically - "putting some images and text on top of the random demo effects". :)
it's not about hard and fast rules. most of the "rules" ive seen here are simply guidelines to help you not fuck up if youre not able to get by otherwise. you dont have to follow them to achieve good direction. :)

but hey, what do i know - ive worked on some of the demos most heavily criticised for their "direction" in recent years (media error springs to mind), so maybe you shouldnt listen to me at all. :)

What about white flashes? To me they are very tempting because they seem an easy way to increase timing density. My ex girl who is an movie editor always got mad about me using them.

smash: All of what you are saying is true, but it doesn't really give any reason why those who are interested in trying different approaches to "direction" can't discuss them without Maali going "OMG! EVERYTHING IS ALLOWED!" in every single thread that touches on the subject. :)

Then another question springs into my mind:

How can you make a demo that is almost purely a 3D flyby (nasca) into something that would never attract comments in pouet such as "Great demo, shame it is only a 3D flyby".

I hope it doesn't look like I want to state that there could be anything like "the formula for a nice demo".

Dude, this is Pouet - oxymoron central. The people who never do diddly squat are the ones who shout the highest. :)

this seriously made me laugh :-)

the 'sad' truth is that most of the time demos are abstract purely due to either or both of the two following restrictions:

a) not enough skill
b) not enough time

guess why our demos are mostly abstract?:-)