158400 polygones and registerForEvent (read/demo/source)

[hondo3000]

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 it even if there are a lot of polygons, and the framerate goes down,
the speed of movement will be correct and only less images will 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:
<a target=_blank class=ftalternatingbarlinklarge
href="http://www.kisd.de/~lutz/crap/highpoly/demo">[url]http://www.kisd.de/~lutz/crap[/url]
/highpoly/demo</a> (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:
<a target=_blank class=ftalternatingbarlinklarge
href="http://www.kisd.de/~lutz/crap/highpoly/highpoly.zip">[url]http://www.kisd.de/~l[/url]
utz/crap/highpoly/highpoly.zip</a>
(it's 6MB too, because its the same w3D model....)

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!!!

[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

[necromanthus]

<blockquote>quote:<br><hr><i>Originally posted by: <b>hondo3000</b></i>
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)<hr></blockquote>

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

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

Secondly, the <b>registerForEvent</b> method is not faster than <b>on
enterframe me</b> method.
It's only an illusion (it works asynchronous and, as you already figure out,
<b>less frames are rendered</b>).
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 <b>NVIDIA's DAWN RenderTest</b> (is gonna be available online soon) has
about 126,000 polys and 8 hi-res textures.
And its file size is about 3 MB ...

<blockquote>quote:<br><hr><i>Originally posted by: <b>hondo3000</b></i>
I think it is a good idea to test every few years how far we can go with
shockwave3D/q]

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

[a?ex]

<blockquote>quote:<br><hr><i>Originally posted by:
<b><b>necromanthus</b></b></i>I do not understand the file size of your demo.
My <b>NVIDIA's DAWN RenderTest</b> (is gonna be available online soon) has
about 126,000 polys and 8 hi-res textures.
And its file size is about 3 MB ...<hr></blockquote>


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...

[ensamblador]

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.

[hondo3000]

@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.

<blockquote>quote:<br><hr>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).<hr></blockquote>

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...

[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

[hondo3000]

i made a little test with a scene which consists of <b>265856 Polygons</b> and
<b>501 Models</b>. Maybe Interesting to some people here that use havok for
collision detection - all models in the scene are fixed rigidbodys with
<b>concave collision</b> 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: <a target=_blank class=ftalternatingbarlinklarge
href="http://kisd.de/~lutz/crap/265856polygons_shockwave3D.mov">[url]http://kisd.de/~[/url]
lutz/crap/265856polygons_shockwave3D.mov</a> (~3MB, webstream quicktime)

if you don't know fraps, you can download it here:
[url]http://www.fraps.com/[/url]
(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!

[necromanthus]

<blockquote>quote:<br><hr><i>Originally posted by: <b>hondo3000</b></i>
... executing code without updating the stage is not that cpu
expensive.<hr></blockquote>

True, but almost worthless if you include motions in that code.
In fact this is the main problem with <b>registerForEvent</b>.
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 <b>too many
frames are skipped</b>.
Tested on 3D worlds containing 15,000 - 150,000 polygons (and <b>tons</b> of
LINGO).
cheers

[hondo3000]

>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!

[necromanthus]

<blockquote>quote:<br><hr><i>Originally posted by: <b>hondo3000</b></i>
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.<hr></blockquote>

If it's impossible to solve the frame rate issue, I prefer a slower but
<b>smoother</b> movement.
Also, using the <b>registerForEvent</b> method (because it works
asynchronous) you'll lose frames even on top machines !
The real solution for all of these is <b>an improved SW3D engine</b>.
Maybe some day ...

[necromanthus]

For those interested:
You get the same results if you replace
<b>gWorld.registerForEvent(#timeMS, #stepon, me, 0, 12, 0)</b>
with
<b>timeout().new("movement", 12, #stepon, me)</b>

But as I said before, I don't like these "asynchronous solutions" ...

[hondo3000]

>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:
<a target=_blank class=ftalternatingbarlinklarge
href="http://www.adobe.com/support/techdocs/329371.html">[url]http://www.adobe.com/su[/url]
pport/techdocs/329371.html</a>
It would be fantastic to include this stuff into director.

But i think there will be a bright future for director! after seeing this <a
target=_blank class=ftalternatingbarlinklarge
href="http://www.youtube.com/watch?v=nq3ZjY0Uf-g">video</a> on what you can do
with some faradaywaves and cornstach and taking in account that " <a
target=_blank class=ftalternatingbarlinklarge
href="http://video.google.com/videoplay?docid=8576567677038063896&q=lordi">lordi
</a> " won the "gran prix european songcontest. Ok, these things don't really
are connected to each other, but they all happen in the same universe and have
to do with "waves"...

[necromanthus]

<blockquote>quote:<br><hr><i>Originally posted by: <b>hondo3000</b></i>
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:
<a target=_blank class=ftalternatingbarlinklarge
href="http://www.adobe.com/support/techdocs/329371.html">[url]http://www.adobe.com/su[/url]
pport/techdocs/329371.html</a>
It would be fantastic to include this stuff into director. <hr></blockquote>

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 <b>Reader</b>, because less than 1% of them
are interested in <b>writing</b> PDF files.

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

[hondo3000]

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...
[url]http://nuttybar.drama.uga.edu/pipermail/dir3d-l/2006-May/010786.html[/url]

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