#Benchmark standard
18 messages in this thread
Dave,
If, and it's a big 'if,' my dual-Alpha estimations are fairly close guesswork,
and if (assuming enough RAM) there's a direct, 1-to-1 correlation between
resolution and rendering time (i.e. a 640×480 takes _exactly_ 4 times as long
to render as a 320×240), then, extrapolated from posted times for P133s at 640,
that hypothetical dual 300MHz Alpha running a fantasied Max for Alpha NT should
clock 62 sec on Chevy at 1280 with mapping on, Pixel Size 1.1. ('course it'll
also run .flc's at about 900 fps, but that's another story…<g>)
The point is that even if my estimate is 50% optimistic (And I'd be real
surprised if it's that far off…), we're already getting under 100 sec on
hardware that's probably less than 6 months off.
Therefore, IMHO, I think we ought to use a higher Pixel Size than 1.1 now, to
give us a fighting chance of having usable numbers a year from now.
Comments, from any and all?
SCL
Steven:
>> Comments, from any and all?
Well, since you asked for it! <bg> I'd vote for rendering, say, 10 or 20
frames to NULL for the test, and getting the total time from 3DS. 3DS renders
subsequent frames faster than the first, especially since the maps only have to
come in on the first frame. The main reason I mention this, though, is that
many of us with networks have all the maps loaded on a server, and the added
time to bring them across the net for a rendering test puts a networked station
at a disadvantage for a single frame.
Also, in a few years when the speeds get closer to real-time (wishful
thinking!), you can easily change it from 20 frames to 100 frames with no other
changes to your benchmark.
Greg Pyros
Greg,
I see your problem with having to pull the maps across a net; only trouble with
rendering multiple frames that I can see is that even a P133 is going to take
more than half an hour to do ten frames at 1280; my poor old DX2/66 would take
overnight. I'd just be afraid that not too many people would be willing to tie
up their machines for that long.
Best suggestion I can come up with to avoid pulling the maps across the net at
render time is to archive the .PRJ to a local map drive, then unzip it. I'm
sure I don't need to explain this to you, Greg, but for the benefit of others
reading this, the archive command in the files pulldown includes all maps
referenced in the scene, automatically.
BTW, you really think we'll ever see real-time rendering? Seems to me like the
faster the rendering gets, the meshes just get bigger so it still takes the
same time! <g>
SCL
Stephen,
If we'll be rendering say 15 frames there'd probably be no reason to use a
resolution higher than 640×480. I think this is a great idea and is a perfect
way to allow it to scale the rendering times.
DM
Greg,
Great idea. I can't believe no one thought of this before. 🙂 It's exactly
what's needed for network setups also. We should be able to stay at 640×480 and
a 1.1 pixel size. In this case I definately think mapping should be on.
Actually now we should be able to use all the defaults.
How about to disk or not. I'd vote to render 15 frames all defaults – no
display and no disk.
What do ya think.
DM
Dave,
I'll go for it.
SCL
Dave et al,
I was just gonna try the 15-frame thing, and lo and behold, the last time I
cleaned up my maps directory, I evidently accidentally deleted 3ds3text.jpg
(foolish me; oughtta be more careful)! I'd hate to have to do a re-install just
to get it back, which appears to be the only way to do it, _unless_ some kind
soul were to email me with it attached…
Thanx in advance,
SCL
Stephen,
It on the way, look for it in your email.
Regards………….Rick – Technical Animations
Rick,
Got it; thanx. I'll u/l 15-frame times this eve, so y'all can see what
suffering us 486 users must endure. <g>
SCL
Stephen,
>>…so y'all can see what suffering us 486 users must endure. <g><<
Oh woow is me….. poor 486 users, I just went from a 386-20 to a P100 last
July. I tested the my two systems last July and the P100 was 28 times faster.
Might there be a difference in rendering times because someone has edited the
rendering parameters in their "3ds.set" file. Or are you still planning on a
project file?
Regards………….Rick – Technical Animations
Rick,
Off the top of my head, the only render parameters in the .set file that might
significantly affect render times and can't change from within 3DS are the
render-band-width and the dithering algorithms, neither of which anyone is
likely to mess with. (Course I could be wrong…)
IMHO, to make a special .prj (or not) ought to be Dave's call, but I kinda
thought that idea fell by the wayside when we went for the more-frames idea
rather that the high-render-time single frame.
SCL
Stephen,
Also in the 3ds.set file is shading mode, antialiasing and pixel size. but ha,
I'm easy(don't tell my wife)if this is what Dave wants to do its Ok with me.
What do you think Dave?
Regards…………Rick – Technical Animations
Rick,
<<Also in the 3ds.set file…>>
Well, yes, Rick, but these are all controllable from within 3DS, (with the
exception of antialiasing filter method, I just checked the docs… BTW, what
is a Bartlett filter anyway, and how does it differ from the regular method?)
so we can tell people what settings to use without having to diddle with the
.set file. — Maybe I misunderstood your original query, but I thought that was
the issue… to tell 'em what settings or create a .prj…
Dave?
SCL
Stephen,
If this is taking too much time, then feel free to say so and we can
discontinue this conversation. I understand if you need to spend your time on
others things.
I am assuming that you believe that a prj file is not necessary, is this
right?. If there is no prj file and everyone uses their 3ds.set file for their
defaults, then we are possibly rendering using different settings. Exactly what
we were trying to eliminate. If we leave it up to each individual to affect the
settings, then this is what we were doing earlier. I also don't think we can
assume that everyone is using a virgin 3ds.set file.
I am in favor of a prj file that everyone downloads and renders without making
any changes, just render the view that comes up when the file is loaded.
Bartlett filter? I suggest that we ask Brandon, he should know<BG>.
Sorry if I was not clear in my previous messages.
Regards……………Rick – Technical Animations
Dave,
Chevy.3ds 640×480, all defaults (mapping on), Pixel Size 1.1, frames 0-14 (15
total), no display, no save.
486DX2/66, 32MB, 256K L2 cache, Hint G486HVL EISA mobo:
_with_ QEMM 7.0: 1:14:58.
No mem mgr; min config (all loads low;
dos mem.exe shows 357K low dos avail.): 1:12:35.
=143 sec improvement
Cool! Thanks for the data Stephen. You're the first one to post results with
the new setup. I will be saving everything and will post the results as they
come in. Weird rendering and not saving anything eh? I've got a 486 also and
will post my results as soon as I'm finished with a project I'm working on.
Possibly Wednesday.
It's also interesting to note the speed gained while not using QEMM. Thanks
again!
DM
Dave,
One interesting facet of the no mem mgr setup is that the status pulldown also
reports an additional half meg or so available to 3DS! (Sometimes that can make
the difference between a swap file or not!)
May I suggest that you post a concise set of parameters under a new thread to
'all,' so we can entice as much participation as possible? I think it would
have more clout if it came from you, as an FA, and a new thread would tend to
compartmentalize it so it wouldn't get confused with the old stuff.
After all, we wouldn't want to be accused of "re-architecting" the benchmark,
now would we? <bg>
SCL
Stephen:
>> After all, we wouldn't want to be accused of "re-architecting" the
benchmark, now would we? <bg> <<
HEY, HEY, HEY We'll have none of that! <G>
– Bob Ritger