14 Replies Latest reply on Jun 9, 2006 7:50 AM by _lw

    158400 polygones and registerForEvent (read/demo/source)

    _lw Level 1
      in the german usergroup was the question how to speed up the frame rate when there are lots of polygons. becaues i tested some time ago with "registerForEvent" i found out that there is something interesting about it.

      most people i guess are using:

      on enterframe me
      my3Dcode
      end

      on exitframe me
      go the frame
      end

      but what happens when you use this code?
      director is doing some stuff before updating the stage. And all things have a fixed order (prepare frame, enterframe, stepframe, exitframe,.... ). this is happening for every frame and it tries to reach the "puppettempo".

      if you now have a 3D scene with a lot of polygons, all calculations are done one time per frame.

      The "registerForEvent" can do things timebased and independent from the exitframe or enterframe handler. And its somehow more "aggressive" than a timeout object.

      If you now use it to move Objects in 3D space with a lot of polygones, the code is executed timebased and independant form the puppettempo. This is cool because even if there are a lot of polygons, and the framerate goes down, the speed of movement will be correct and only less images are rendered.

      This is a good thing because the app will not become slow, it will only render less images.

      If you want to see what i am talking about, you can take a look at this online demo:
      http://www.kisd.de/~lutz/crap/highpoly/demo (6MB)

      sorry for the filesize, but this is a extreme number of polygons...

      here is the sourcefile if you want to take a look at the code:
      http://www.kisd.de/~lutz/crap/highpoly/highpoly.zip
      (it's 6MB too, because its the same w3D file in it....)

      By the way, on my machine it runs on about 8fps when the camera shows all models, and about 20 fps when the camera is close to one of the models. (AMD 1.3 GHz, good graficcard)

      I would like to hear how it performs on your machines, any comments are welcome!
      I think it is a good idea to test every few years how far we can go with shockwave3D

      Oh, and don't switch to software mode!!! this will reduce the framerate in this demo to 1 per minute!!!
        • 1. Re: 158400 polygones and registerForEvent (read/demo/source)
          nick_kang
          24 to 44 fps in DX7
          32 to 48 fps in OpenGL
          (Intel 3.4G, nVidia 7800)

          What surprised me is OpenGL is faster in this example. In practically all my previous testing, DX7 has been faster across a variety of hardware setups (granted, with much lower poly scenes). So it seems OGL has a measurable performance advantage for high polycounts?

          Interesting, I never thought of using registerForEvent() as a general purpose timer. You're right, it does seem to run at a higher priority, meaning callbacks are triggered more accurately than regular timeOuts. Normal callbacks using timeOut objects are only triggered after the specifed milliSeconds have elapsed (*), while the SW3D timer seems to be able to trigger the callback before and after the specified interval, resulting in a more accurate frequency overall.

          (*) This is why the displayed framerate in this demo is slightly inaccurate compared to the framerate reported by an external utility like FRAPS. By the time fps_update() is called, there is a good chance more than 500 ms has elapsed, thus resulting in a higher FPS value.

          That said, I think it's better to avoid callbacks altogether. By calculating the elapsed time per frame and animating all scene objects based on that, you ensure all animation is time-based (just like your above example). In addition, you have the flexibility of pausing and varying the speed of your simulation on-the-fly, independent of the achieved framerate (or rendering speed).

          -nick
          • 2. 158400 polygones and registerForEvent (read/demo/source)
            Necromanthus Level 2
            quote:

            Originally posted by: hondo3000
            By the way, on my machine it runs on about 8fps when the camera shows all models, and about 20 fps when the camera is close to one of the models. (AMD 1.3 GHz, good graficcard)

            Hi Hondo.
            You're a manic miner and I like that (LOL).

            First of all, remove the #lod and the #meshdeform modifiers from beginsprite me (do not count the polys) and check out the frame rate again. You'll be surprised ...

            Secondly, the registerForEvent method is not faster than on enterframe me method.
            It's only an illusion (it works asynchronous and, as you already figure out, less frames are rendered).
            Also, this method can't be used in serious projects (such as "removeFromWorld, modelsUnderRay, addToWorld") because you'll get visual artifacts.

            I do not understand the file size of your demo.
            My NVIDIA's DAWN RenderTest (is gonna be available online soon) has about 126,000 polys and 8 hi-res textures.
            And its file size is about 3 MB ...


            quote:

            Originally posted by: hondo3000
            I think it is a good idea to test every few years how far we can go with shockwave3D

            SW3D is obsolete, but has no competitors if we're talking about Web3D.
            And it seems nothing can change this situation until 2011. Even DirectX 14.
            But Adobe is not here ...


            keep up the great work there
            cheers
            • 3. Re: 158400 polygones and registerForEvent (read/demo/source)
              a¿ex Level 1
              quote:

              Originally posted by: necromanthusI do not understand the file size of your demo.
              My NVIDIA's DAWN RenderTest (is gonna be available online soon) has about 126,000 polys and 8 hi-res textures.
              And its file size is about 3 MB ...



              It wouldn't surprise me, if the big file was authored with cinema4d and the smaller one with 3DSMax...
              I recently noticed, that the c4d exporter not only has annoying quirks and solves the twisted axis problem in a very hackish and annoying manner, but also it produces bigger files, which on top of that are worse quality-wise compared to their 3DSMax equivalents.

              i don't know, what they made with that c4d exporter, but i can't recommend c4d for sw3d authoring unfortunately.
              I like c4d, you can achieve very good results in c4d, I like the way the authoring environment works, how it is customizable and the most important, I like the open API to extend the app via plugins. (it is very easy to write a plugin to automate tasks with a simple text editor and some basic knowledge of scripting) I wrote a couple of plugins to handle the twisted axis, to optimize the scene before exporting to sw3d and to replace "c4d instances" with groups, which then in director are replaced again with clones. (thus cutting down filesize significantly, as only unique modelresources go into the w3d file).

              At some point I noticed, that there are other shortcomings in the exporter, which I can't circumvent. :-(
              rendered my work with c4d plugins pretty much useless...

              • 4. Re: 158400 polygones and registerForEvent (read/demo/source)
                ensamblador Level 1
                8-20 DX7
                4-4 OGL
                Laptop HP
                3.06 GHZ
                ATI Mb RADEON 9000

                I hope, nearly in future, Director uses DX9 or D3D10 for its graphic engines.
                At the moment DX7 it what it makes it obsolete.

                Congratulations Hondo.

                • 5. Re: 158400 polygones and registerForEvent (read/demo/source)
                  _lw Level 1
                  @nick
                  i have here under openGL a little bit more performance too, made me surprised too...

                  i had only few minutes to write the demo and i only changed the fps counter from the chrome lib a little bit... you are right, in this example it is not very accurate, but can be done better.

                  quote:

                  That said, I think it's better to avoid callbacks altogether. By calculating the elapsed time per frame and animating all scene objects based on that, you ensure all animation is time-based (just like your above example). In addition, you have the flexibility of pausing and varying the speed of your simulation on-the-fly, independent of the achieved framerate (or rendering speed).


                  Thats right, i only came to this idea bcause i work at the moment on a project where i need to execute lingo on different machines at the same frequency, this is because its multiplayer and all code things happen on fixed intervals. This works even on slow machines very well or in software mode.

                  @necromanthus

                  to the first point:
                  i wanted to have all polygons in the szene to show what the "registerforevent" thing is doing, only thing that could be useful is to register and unregister scripts. At the moment its only possible to "unregisterallevents"

                  to secondly:
                  i tested here both methods and i get the same framerate, only thing is that "on enterframe" the movement is slower because the lingo code is not updated on 85 fps. Its not that the "registerforevent" makes less frames per second than the other way, just that it is not nessesary to mesure the passed milliseconds to get the same speed of movement. talking of raybased collision detection, it's is easier to work with a fixed values for tolerances.
                  but you are right, i made no tests with removefromworld and addtoworld....

                  this method is really usefull when it is important to update the code on fixed frequence. At the moment i use Havok for collision detection and it works very well. (i will show a working example in a few days i hope, only have to work on the grafics...)

                  @ a¿ex
                  Yes, i use Cinema4D and spend a lot of time with fixing the problems... the file is that big because it contains 4 models and each has its own modelresource. it is possible to fix this, by making copies of the model, but i thought to keep this demo as simple as possible.
                  By the way, i tried to export it as one model with all polygones in it, but cinema4D crashed everytime when more than 100 000 polygons or so where in one model. Maybe its only on my machine, but i can live with that because its no good idea anyway to export models with this large number of polygons...
                  I hope the interest of the cinema4D users on shockwave3D will grow a litte bit and maxon will update the exporter... but how can the interest in the exporter grow if its not well done... ...

                  i had a lot of headache because of it, but i have no chance to switch over to a different app light max or maya because we do not have it in school... life is sometimes very hard.... (i just finished a shockwave3D engine for cinema4D users)



                  @ all
                  thanks for looking into this thing and giving feedback here! from day to day i understand director a little bit better and really hope it will get a updated shockave3D engine. For me, as a design student its really hard to get into all the code stuff, sometimes its not that easy to understand how things work under the surface.

                  I never tried to export a shockwave3D file with that amount of polygones before, but this test gave me some new ideas no how to optimize things.

                  If i find the time i will do some more tests with unoptimized models

                  i never tried to use models with alot of polygons, but a few minutes ago i tested this movie without setting the #lod modifier and using but using:

                  sprite(1).targetFrameRate = 85
                  sprite(1).useTargetFrameRate = TRUE

                  which is reducing the number of rendered polygons on my machine on something between 3000 -5000 and a resulting framerate of 55fps. just wanted to add this here because its realated to hipoly models in shockwave3D and maybe some people never took alook at this option...



                  • 6. Re: 158400 polygones and registerForEvent (read/demo/source)
                    Michaelcov
                    AMD Athlon 2.2GHz
                    NVIDIA GeForce 6200

                    When showing all models...
                    32 FPS - openGL
                    28 FPS - directX

                    Using removeFromWorld to remove models unseen inside buildings at the very start of game is very effective for me by the way. With triggers to add the models later. By then, the framerate has had chance to climb higher. Upto 10 to 15 fps more when I remove 1200 polys at the start.

                    I gained only 5 fps when I removed 5 rays (just for test, I need the rays)

                    If you are careful, you can produce light rain with particles using as little as 40.

                    Thanks

                    MichaelUK
                    • 7. Re: 158400 polygones and registerForEvent (read/demo/source)
                      _lw Level 1
                      i made a little test with a scene which consists of 265856 Polygons and 501 Models. Maybe Interesting to some people here that use havok for collision detection - all models in the scene are fixed rigidbodys with concave collision geometrie. which means that the hole mesh is used to check for collision, not a optimized proxie or a "#sphere"

                      havok seems to be very optimized for checking lot of polygons with fixed rigidbodys. I did not upload this file because it takes too long to process the geometry before it starts to play, on my old 1.3 Ghz it seems to need some minutes and loading the 9MB seems to be very ram-intense...

                      but i made this little video with Fraps to show here. i use the registerforevent method to execute lingo. the image update of the stage is done with "go the frame" on "exitfame" handler. And i have to say that fraps took me away some half of the performace... without fraps it is min 20 fps and max 75 fps

                      fraps video: http://kisd.de/~lutz/crap/265856polygons_shockwave3D.mov (~3MB, webstream quicktime)

                      if you don't know fraps, you can download it here:
                      http://www.fraps.com/
                      (this is just in case someone want to use shockave3D for machinima stuff...)

                      somehow fraps records only if shockwave is set to openGL rendering...

                      @Michaelcov
                      and i think it is really a good idea to create systems that remove polygons from the the rendering. The rendering of the 3D images is really the hard part for shockwave, executing code without updating the stage is not that cpu expensive.

                      cheers!

                      • 8. Re: 158400 polygones and registerForEvent (read/demo/source)
                        Necromanthus Level 2
                        quote:

                        Originally posted by: hondo3000
                        ... executing code without updating the stage is not that cpu expensive.


                        True, but almost worthless if you include motions in that code.
                        In fact this is the main problem with registerForEvent.
                        Because it works asynchronous, on entry-level machines (Celeron/Duron 1GHz, 256MB RAM, obsolete Vcard) your movie seems to run faster.
                        But as I said before, it's only an illusion (because the FPS value is not higher).
                        Now the worst part: the motion looks horrible, and that's because too many frames are skipped.
                        Tested on 3D worlds containing 15,000 - 150,000 polygons (and tons of LINGO).
                        cheers



                        • 9. Re: 158400 polygones and registerForEvent (read/demo/source)
                          _lw Level 1
                          >True, but almost worthless if you include motions in that code.
                          Even worthless if you end up in slowmotion.

                          Anyway it's bad when the framerate goes down, but if this happens, i think its better to give the illusion of movement as doing it not. i think its a good idea doing this in the way nick suggested, by calculating the motionvector depending on the elapsed time without using "registerForEvent". But really depends on the project if this is nessesary or not.

                          regards!



                          • 10. Re: 158400 polygones and registerForEvent (read/demo/source)
                            Necromanthus Level 2
                            quote:

                            Originally posted by: hondo3000
                            Anyway it's bad when the framerate goes down, but if this happens, i think its better to give the illusion of movement as doing it not.


                            If it's impossible to solve the frame rate issue, I prefer a slower but smoother movement.
                            Also, using the registerForEvent method (because it works asynchronous) you'll lose frames even on top machines !
                            The real solution for all of these is an improved SW3D engine.
                            Maybe some day ...
                            • 11. Re: 158400 polygones and registerForEvent (read/demo/source)
                              Necromanthus Level 2
                              For those interested:
                              You get the same results if you replace
                              gWorld.registerForEvent(#timeMS, #stepon, me, 0, 12, 0)
                              with
                              timeout().new("movement", 12, #stepon, me)

                              But as I said before, I don't like these "asynchronous solutions" ...
                              • 12. 158400 polygones and registerForEvent (read/demo/source)
                                _lw Level 1
                                >timeout().new("movement", 12, #stepon, me)

                                I tested this one Minute ago and it is really not the same, the "registerForEvent" is more accurate then the timeout objekt. Tested this with the demo i posted in the beginning of this thread and it seems that it is not skipping frames.

                                >But as I said before, I don't like these "asynchronous solutions" ...
                                Ok, i really need this solution for my current projekt to execute code on different machines on the same tempo. Because it has to be possible to use "fraps" to record and for some other stuff related to multiuser code. In this cases its really usefull.

                                >The real solution for all of these is an improved SW3D engine.
                                >Maybe some day ...
                                You are absolute right! I hope that some of the acrobat3D stuff will find a way into shockwave3D. I found this document on supported file formats that can be used with acrobat3D:
                                http://www.adobe.com/support/techdocs/329371.html
                                It would be fantastic to include this stuff into director.

                                There will be a bright future for director! After seeing this video on what you can do with some faradaywaves and cornstach and taking in account that " lordi " won the "gran prix eurovision" songcontest. Ok, these things don't really are connected to shockwave3D, but they all happen in the same universe and have to do with "waves"...


                                • 13. Re: 158400 polygones and registerForEvent (read/demo/source)
                                  Necromanthus Level 2
                                  quote:

                                  Originally posted by: hondo3000
                                  You are absolute right! I hope that some of the acrobat3D stuff will find a way into shockwave3D. I found this document on supported file formats that can be used with acrobat3D:
                                  http://www.adobe.com/support/techdocs/329371.html
                                  It would be fantastic to include this stuff into director.


                                  I agree.
                                  I can't figure out why Adobe is pushing Acrobat3D, because in my opinion (and I'm not the only one !) this app has no future.
                                  Most people (>99% of them) use Acrobat (and the PDF format) to read some text (with few embedded images) and nothing more.
                                  In fact I'm talking about Acrobat Reader, because less than 1% of them are interested in writing PDF files.

                                  Coming back to Director Shockwave, I'd love to see it able to import 3DS, OBJ, WRL and MD3 files.

                                  • 14. Re: 158400 polygones and registerForEvent (read/demo/source)
                                    _lw Level 1
                                    sorry that i bring this thread up again...

                                    @registerForEvent:
                                    tested now together with directtostage=false, so in some cases, talking about machinima, it can be useful to grab the 3Dimages to save them als a sequence of images. on my machine the framerate went down to something about 25-30 fps... but i did not tested to store images on the fly and to save them. but this is just a suggestion, maybe useful for some folks... but now i think this topic is done ;)



                                    @necromanthus:
                                    >Coming back to Director Shockwave, I'd love to see it able to import 3DS, OBJ, WRL and MD3 files.

                                    i just remembered this thread in the mailinglist, and thought that it is something to add here. Don't think this will be in the next release of Director, but good to know that we are not the only ones that see here a opportunity...
                                    http://nuttybar.drama.uga.edu/pipermail/dir3d-l/2006-May/010786.html

                                    now i will bring up the other topic again, about the future of director and shockave3D :)