Re: Simple modeller

["Stephen J Baker" <sjbaker@link.com>]

On Thu, 24 Oct 2002, [ISO-8859-1] Gregor Mückl wrote:

> Steve Baker wrote:
> >
> >   * You have to spend a lot of effort creating complex material
> >     and lighting setups - none of which is actually likely to show
> >     up in your game.  One slip of one of hundreds of controls and you
> >     have a black screen.  All I really need is a 'headlight' (so I
> >     can see what I'm modelling) and Specular/Diffuse/Ambient/Emission
> >     for each colour.
> >
>
> I doubt that object material settings can be much simpler than that,
> actually. Even for games. As a matter of fact the material system is too
> simple to create appealing scenes.

The problem is that material setting are something that are unique to
the game engine.  You can't possibly hope that I'll implement a
renderer that implements exactly the set of things that Moonlight
provides in it's sliders.

So, you have two options:

  1) Abandon hope of having WYSIWYG - and just provide something
     *simple* so I can see my model without having to twiddle a
     gazillion sliders.

  2) Provide renderer plugins so polygon rendering can be replaced
     (along with the entire material/lighting properties dialog and
     data store) with whatever my game needs.

> >   * Weird/cranky user interface - it takes over the whole screen (which
> >     is *really* inconvenient), it screws up X (or maybe KDE) so after
> >     it's exited, my windows pop up in weird orders and various scroll
> >     bars on quite unrelated tools don't render correctly.  It uses
> >     keyboard characters as mouse button modifiers.  It's not *quite* as
> >     weird as Blender - but it's definitely fallen into the same traps.
> >
>
> These bugs are new to us. Could you please send me more info (and
> perhaps some screenshots) on this exiting problem? I will forward this
> to our own mailing list.

Yep - I'll get to that this evening (time permitting).

> >   * There doesn't seem to be a way to have multiple models on screen
> >     at once - that combined with it's full-screen-ness will make
> >     building complex scenes with multiple models difficult.
> >
>
> Well... you cannot have more than one scene simultaneously. Even some of
> the most popular and expensive modellers out there don't allow this.

No - but at least you can run multiple instances of them.  That's
virtually impossible with Moonlight because it takes over the entire
screen.  (Why do that BTW?)

> >   * It's annoying that when you are playing with colours and such,
> >     you have to keep hitting 'apply' buttons before anything happens.
> >     With a modern graphics card I shouldn't have to do that.
>
> For really complex scenes real time updates would still not be fast
> enough. It is *really* annoying when you try to drag a slider to a
> certain position and it jerks there slowly in 10 steps of 3 seconds
> each. So realtime update is a big DON'T - at least in my oppinion.

But for GAMES, it is the case that your scene has to render at 60Hz,
so it seems reasonable that the modeller's renderer should be able
to update it at something like 10Hz...preferably more.

This is the kind of thing that tells me that you aren't thinking
of games designers.

PrettyPoly uses the same rendering code as my games - so the
performance within the modeller is identical to that in the game.
Obviously you can't always manage that (eg you'll want to render
a large chunk of a game level without culling - and you'll want
to add wireframes and grids and such...but then you'll probably
be using simplified single-pass rendering) - but it should still
be fast enough to be interactive.

> >   * There don't *seem* to be places to enter things numerically.
> >     This is a pain when you want things to line up nicely and have
> >     exact known sizes.  A game modeller needs to be more like a CAD
> >     package than an 'artistic' tool.
>
> These dialogs are there. They should appear in the bar on the right. I
> can't remember how to open them, though. Give the "Dialogs" menu on the
> left a try.

I didn't see anything - but like I said - I only spend a short time
playing.

> >   * It seems to want you to store everything in 'Projects' which seem
> >     to wrap up numbers of models, materials, etc.  Most of the time,
> >     I just want to load a single, simple model file - change it and
> >     write it out again.
>
> You should let Moonlight manage your models, materials, etc for your
> game project.

Why?  Moonlight is only a small part of my overall management problem.
I have sounds and scripts and all sorts of other data files.  I need
to choose how to organize things like per-level models and general
models, things that are only in cut-scenes and things that are in
main play.  Things that are ray-traced into flat icons or other
textures.

Taking over the world only works in a situation where the entire
world is a part of Moonlight's work.  That's typically the case
in a raytracing environment - but it's madness for something of
the complexity of a game.

> To feed this data into your game engine you need to export
> it. For exporting an XML im-/exporter is planned which can dump (and
> read - of course) every single byte of information ML keeps on the
> scene. Other exporters will be available, too. And once the plugin
> architecture is fully working it will be relatively easy to add one's
> own exporters.

...and importers?

> But it seems that you've looked at Moonlight long enough to give this
> extensive review.

It's not an extensive review - it's my reactions to playing with it
after one evening.  I made that very clear - and would welcome corrections
on things I got wrong.

> I'd like to have some more info about the drawing
> bugs, so we can try to fix it (we've had much trouble with the drawing
> code before).

Sure - it's not the 3D rendering - it's the contents of file selectors
and such.  I'll try to get a screenshot for you sometime tonight.

What's much more worrying is how it screws up X (or KDE) even after
Moonlight has exited.  You mention in the README about the key repeat
being screwed if Moonlight crashes - but this seems more problematic
than that (and Moonlight hadn't crashed).

This could be a problem in KDE 3.0.0 - I havn't been using it for long,
so I'm not familiar with all it's quirks.

One symptom was (for example) that I'd bring up an image in 'xv',
then hit the right mouse button to bring up the GUI for xv.  Normally,
the xv GUI pops up on top of the image...this time it popped up
under the viewer window.  I've never seen it do that before so I
rebooted KDE, and re-ran xv - this time, it worked correctly. Then
I re-ran Moonlight and exited cleanly - now xv is fsck'ed again.

There were other oddities such as the slider in the email window
of Mozilla not rendering properly (it worked OK - just didn't draw
right).

It's hard to imagine what Moonlight could be doing to cause this
effect - so I'm betting it's a KDE 3.0.0 bug.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@link.com           http://www.link.com
Home: sjbaker1@airmail.net       http://www.sjbaker.org