pouët.net

Scali information 955 glöps

• general:
• level: user
• personal:

• demo Windows Awakening by Darkzone [web]
• Very nice, much better than any Shockwave stuff I've seen so far...
  Looks like a true demo to me, nice, complex, abstract, shiny objects.
  
  I really liked the last object, with the raytraced shadows, looked amazing.
• rulezadded on the 2003-06-05 11:25:38
• demo Windows Awakening by Darkzone [web]
• Proper download link
• isokadded on the 2003-06-05 11:14:28
• demo Amiga OCS/ECS Maximum Overdrive by The Special Brothers
• Wow, quite a good 3d demo, especially considering it's such an early one.
  
  (by the way, what WAS the first 3d demo?)
• rulezadded on the 2003-05-19 14:28:11
• demo Windows World Domination by Odd
• And why should I make a demo? To prove myself? I have nothing to prove.
  Besides, I would most likely not put metaballs in a demo, because they are the most boring thing you can possibly do with Marching Cubes, and have been done to death already. And if I did, I would try to make them look good, rather than having ugly slow metaballs on screen and printing '640' over them.
  
  Anyway, demomaking is not for me. And I don't pretend that it is either, so I don't see why I would have anything to prove.
• isokadded on the 2003-05-06 11:41:36
• demo Windows World Domination by Odd
• You jealous, plek? Sounds like it anyway.
  
  Anyway, I am probably biased, but that 'proof' program doesn't seem to change much after the first few seconds...
  I wonder if anyone else agrees with me on that.
  If it really keeps adding balls all the time, I can only wonder why neither the speed nor the appearance seem to be affected much, if at all (I would say more balls == more overhead == less performance. I would also say more balls == more energy == more volume... Since it appears that you don't adjust the threshold while adding the balls, I can't understand how the volume doesn't grow at all, and in fact actually appears to shrink at times). And I guess that even the coder himself has to agree that at no point in time it actually LOOKS like there's anywhere near 640 balls on screen.
  
  If there really are 640 balls in there, I wonder why the hell you bothered, since the appearance is not affected (the field function must just 'saturate' and nullify all balls added after about... 100?), and the appearance in general is not exactly good.
• isokadded on the 2003-05-06 10:16:34
• demo Windows World Domination by Odd
• Okay, if I am off, please tell me the right solution then... That's the least you can do, if you don't want to release your sourcecode (why not?)...
  Also, 40x40x40 is such a low gridsize... Even plek uses more on his PII-300 :)
  
  iblis: I hate being flamed and insulted for no good reason at all.
  I mean, I don't care whether there really are 640 balls or not... I only made the statement that it didn't look like there were 640 balls. I also gave an explanation why I thought so. And then some people found it necessary to insult me etc... So I tried to visualise my explanation... And I get flamed even more.
  
  So, if I'm wrong, don't flame me, prove it. I have not seen any proof yet. Have you?
• isokadded on the 2003-05-05 23:41:40
• demo Windows World Domination by Odd
• Yes, from the little info that he has given so far, I was able to guess that he uses an energy function such as the one presented by Paul Bourke, which drops to 0 for enery source that are 'too far away'...
  So what you can do is this:
  Divide your grid up in sectors... For each sector, create a list of 'possible energy sources' by discarding those whose value drops to 0 in that sector.
  Now as you evaluate the grid in each point, you only have to evaluate the sources in the list of the current sector.
  This ofcourse means that having 640 balls is pretty much impossible. The way this thing is tweaked, it probably discards more sources than it actually uses in general. The effect is about the same as ..say.. 64 balls?
  
  Am I right here? Or am I completely off?
• isokadded on the 2003-05-05 23:27:19
• demo Windows World Domination by Odd
• Gee, I hadn't thought of that!
  I never visited Paul Bourke's wonderful page!
  
  Mind you, this means that you don't actually HAVE 640 balls, you realize ofcourse, 'dummy', since the bounding box eliminates them (probably many).
  So my point still holds... You can do the same with much less balls...
  
  Also I still haven't heard about that gridsize...
  And you're not going to explain, let alone send the source are you?
  
  You sir, are full of shit. Bye now.
• isokadded on the 2003-05-05 23:04:55
• demo Windows World Domination by Odd
• Oh, and if you really want to convince me, you can always send me the source.
• isokadded on the 2003-05-05 22:25:35
• demo Windows World Domination by Odd
• You can use a different energy-function, but that still won't make the code fast enough (regardless of all the flames about my code, I for myself know that it is a reasonably decent implementation speed-wise, and while one can probably come up with a considerably faster implementation, getting 3-4x the framerate as my code is simply impossible).
  By the way, when are you going to mention the gridsize you used? That is vital information in this discussion you know. Need to hide something?
  
  Also, then there's the point of WHY?
  Why would you use 640 balls with a tweaked/replaced energy-function, if the end result is more like what you'd get with 64 balls and a different energy-function?
  
  1) The 64 balls version will always run faster than the 640 balls version (hey you could even add some extra balls!)
  2) Nobody can verify that there actually are 640 balls anyway, so if it looks the same, who cares.
  
  I'd go for the faster implementation, if both give the same result. And I think any sane coder would do the same.
  
  Bye now.
• isokadded on the 2003-05-05 22:22:07