home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / amiga / graphics / 5242 < prev    next >
Encoding:
Text File  |  1992-07-21  |  2.7 KB  |  53 lines
  1. Path: sparky!uunet!darwin.sura.net!mips!zaphod.mps.ohio-state.edu!uunet.ca!canrem!dosgate![james.kewageshig@canrem.com]
  2. From: "james kewageshig" <james.kewageshig@canrem.com>
  3. Newsgroups: comp.sys.amiga.graphics
  4. Subject: motion blur...
  5. Message-ID: <1992Jul22.854.7999@dosgate>
  6. Date: 22 Jul 92 00:24:19 EST
  7. Reply-To: "james kewageshig" <james.kewageshig@canrem.com>
  8. Distribution: comp
  9. Organization: Canada Remote Systems
  10. Lines: 41
  11.  
  12. mark@calvin..westford.ccur.com (Mark Thompson) writes:
  13.  
  14. MT>In article <1992Jul15.134812.6943#jhunix.hcf.jhu.edu> johnh@jhunix.hcf.jhu.edu (John J Humpal) writes:
  15. >  Is the coding for gen. motion blur very complex?
  16.  
  17. MT>That would depend on how innovative the coders wanted to be in order to speed
  18. MT>it up. A simplistic approach of merely doing additional sub-frame time
  19. MT>renders and compositing is not too much effort, but it is one more thing
  20. MT>that will take time away from chasing bugs and adding other features. But
  21. MT>considering the attention such a feature might draw, it is most likely
  22. MT>worth giving it some priority.
  23.  
  24. The best motion blurring I've seen for the Amiga was done with 
  25. ImageMaster.  It really does blur the area specified in the direction
  26. you specify.  I've seen other ways of doing motion blurring on animation,
  27. one being in 'Animation Station' (under-rated), which I think works
  28. on the same principal as you described, where the previous 5 or so frames
  29. are added to the current frame at different intensities, sorta a 
  30. 'stagger-strobe' effect.  It worked pretty good on some old HAM animations
  31. of mine (not to mention that HAM indirectly helped with the fringing..).
  32.  
  33. What would be a 'hack' way of doing it would be to be able to specify
  34. what polygons are able to 'blur' and have the renderer blur that
  35. polygons colour in the opposite direction that it is moving in. 
  36. I don't know if this would actually work, or what kind of math is involved,
  37. just an idea...  
  38.  
  39. Actually just thinking back to your AC article, you could kinda do it 
  40. with the 'transparency' setting in LightWave, like for rocket blasts.
  41.  _________________________________________________________________________ 
  42. |0 ___ ___  ____  ____  ____                                             0|\
  43. |   \ \//    ||    ||    ||                James Kewageshig               |\|
  44. |   _\//_   _||_  _||_  _||_      UUCP: james.kewageshig@canrem.uucp      |\|
  45. |   N E T W E R K    V I I I    INET: james.kewageshig%canrem@lsuc.on.ca  |\|
  46. |0_______________________________________________________________________0|\|
  47.  \_________________________________________________________________________\|
  48. ---
  49.  ■ DeLuxe² 1.25 #8086 ■ Head of Co*& XV$# Hi This is a signature virus. Co
  50. --
  51. Canada Remote Systems  - Toronto, Ontario/Detroit, MI
  52. World's Largest PCBOARD System - 416-629-7000/629-7044
  53.