Where will the pair be going in the future?

I imagine that if the project is not abandoned, they will continue to
grow closer and closer. Eventually (in a far future?) it would be
possible to use one program with the ease of use and visualization of
Moray, and all the scripting power of straight pov code.

In an ideal world, the end product would be a renderer that is a good
tool for the most diehard POVer, but also something a complete newbie
can jump into and feel comfortable.

Ah well... it's a nice dream. Every step Moray takes is one step closer
to realising the dream.

Post a reply to this message

Perhaps we ought to consider making Moray more general- its current
abilities to export
only to POV-Ray hamper its success. Moray is possible the BEST SOLIDS
MODELER available for the price. As such, it would be nice if it could
export to other renderers that accept solids(BMRT...) so that it would
become a bit more portable, and reach a larger audience(read customer
base).

Simon de Vet wrote:

> Where will the pair be going in the future?
>
> I imagine that if the project is not abandoned, they will continue to
> grow closer and closer. Eventually (in a far future?) it would be
> possible to use one program with the ease of use and visualization of
> Moray, and all the scripting power of straight pov code.
>
> In an ideal world, the end product would be a renderer that is a good
> tool for the most diehard POVer, but also something a complete newbie
> can jump into and feel comfortable.
>
> Ah well... it's a nice dream. Every step Moray takes is one step closer
> to realising the dream.



--
The problem with the gene pool is that there is no lifeguard.

Post a reply to this message

Hi Alex Magidow, you recently wrote in moray.win:

> Perhaps we ought to consider making Moray more general- its current
> abilities to export only to POV-Ray hamper its success. 
Yes, this is the direction we are taking. While we still anticipate
POV-Ray as being the renderer we will support most closely, other
renderers are definitely on the list of things to support.

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

POvray should contine to be developed as it is, a seperate entity. its one
of the render engines strongest points compared to other commercial high end
software. (more features would not go amiss tho - and maybe quicker
ingegration of the various patches)

Moray on the other hand, needs to be able to keep up with the latest POVray
developments (ie UVPOV) , the best and simplest method i can think of is its
plugin system, which seems to have gotten over most of the early hiccups

Moray would vastly benifit from a script type plugin, for example, one that
you can paste a chunk of while do's into and it will build the output as
moray objects, on that same note the ability to parse POV script would be a
real step forward - even a limited subset of the full language would be
extremly usefull - however wether this should be as a plugin or part of
moray depends on who would be best suited to write and maintain it (i think
Lutz would shudder somewhat if this was lumped on his shoulders!!)

A simpler plugin system (as discussed on sdk-list) would be a real
advantage, something allong the lines of beginner VB would be perfect - draw
your UI then write simple and easy to learn code to power it.

(I have just started VB6 and i am amazed at how short the learning curve
really is - ok there are 1 million and 1 things i am doing badly, my code is
about as optomised as a pair of giant clown shoes with running spikes on,
and there are thousands of things i just dont know how to do)

But, would a moray plugin system need anything more complicated than drawing
common controls, naming them, and some form of basic code to tie it all
together, especially if the plugin is only going to manipulate or create
objects in moray.

more complex plugins may well be suited to the current VC SDK system, think
about it, if your going to program a new render engine or animation system,
and think you can accomplish this at the outset, you most likely already use
VC or another high end dev tool.

Moray would also benifit from support of other solids based render engines
(some one mentioned BMRT) but this would ONLY be worth doing if moray could
be as compatable with that system as it is with POVray, being able to use a
only a subset of the target render engines capabilities would be almost
pointless - a bit like the early polyray plugin.

Moray would also benifit from an overhauled patch modelling system,
personally i find the current system a nightmare to use properly, and as
spatch seems to be dead in the water these days maybe a merger of sorts
would be a good idea.

Better CSG evaluation is also needed, having played with truespace recently
and watched it perfectly evaluate CSG objects on screen, moray seems quite
clumsy compared.

a texture cache would be nice for the tex editor, so libraried textures once
rendered can be previewed instantly. but while this would not be a complex
task to program, having a large chunk of valuable HD space taken up may not
be what everyone wants.

object masking would be essential as well, meaning the ability from within
moray to turn of parts of the scene, replacing them with a single large
bounding box. currently i have difficulty modelling when this start to get
very complex - there are just to many objects for me to be able to see what
i am doing, even though where ever possable i model everything seperatly and
combine later. this would also help to combat big scene slowdown.

another thing that would help with big scene slowdown, would be a better
method of redrawing the scene, Moray tends to overdraw the same pixel many
many times (once for every object that intersects that pixel).

the abitlty to color objects in the modelling windows would be nice also, i
dont know about anyone else but playing hunt the grey object in a haystack
of grey objects gets a little tricky.

====

Ok thats me about requested out  :), dont get me worng, moray is one of my
favorite modelling tools and i love it to bits.

Rick

Post a reply to this message

Alex Magidow wrote:

> The problem with the gene pool is that there is no lifeguard.

Yes, I know that it's got nothing to do with moray but a lifeguard (in
human scales) would be the death of the genepool. That ain't working and
history shows it.

Post a reply to this message

Hi Rick, you recently wrote in moray.win:

> [lost of good suggestions snipped]

Thanks for the great feedback. I'll make sure we think about all your
points. One of them is already in the next version (the Material
Editor and Library cache the textures).

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

> Moray would also benifit from an overhauled patch modelling system,
> personally i find the current system a nightmare to use properly,
> and as spatch seems to be dead in the water these days maybe a 
> merger of sorts would be a good idea.

Indeed!
It would already help a lot if you could change the patches in 3D
windows (there is at least one in the edit tab, normally).

> object masking would be essential as well, meaning the ability from
> within moray to turn of parts of the scene, replacing them with a 
> single large bounding box. currently i have difficulty modelling 
> when this start to get very complex - there are just to many 
> objects for me to be able to see what i am doing, even though where 
> ever possable i model everything seperatly and combine later. this 
> would also help to combat big scene slowdown.

there are methods to do this (global visibility settings- check the
manual to understand the system). The problem is not that this doesn't
exist, but I think it's too difficult to use, so I've never actually
used it.

> another thing that would help with big scene slowdown, would be a
> better method of redrawing the scene, Moray tends to overdraw the 
> same pixel many many times (once for every object that intersects 
> that pixel).

Perhaps it would help if spheres (, cylinders, patches, etc.) wouldn't
just always consist of the same number of lines. What if this depended
from their actual pixel size of the screen? While big spheres could
gain accuracy, smaller ones could be drawn with fewer lines, thus
speeding up things a lot.

=====

Hey! Even more suggestions! There will soon be enough for Moray 4, 5,
...

Florian

Post a reply to this message

Simon de Vet wrote:

> Where will the pair be going in the future?
>
> I imagine that if the project is not abandoned, they will continue to
> grow closer and closer. Eventually (in a far future?) it would be
> possible to use one program with the ease of use and visualization of
> Moray, and all the scripting power of straight pov code.

>
>
> In an ideal world, the end product would be a renderer that is a good
> tool for the most diehard POVer, but also something a complete newbie
> can jump into and feel comfortable.
>
> Ah well... it's a nice dream. Every step Moray takes is one step closer
> to realising the dream.

Well the scripting as a plug in that would allow users of Moray to copy
snippets of Pov code into the "editor window" then let moray make the
object it's way from the code would be a GREAT help IMHO....

Post a reply to this message

Hi Florian Fischer, you recently wrote in moray.win:

> there are methods to do this (global visibility settings- check the
> manual to understand the system). The problem is not that this doesn't
> exist, but I think it's too difficult to use, so I've never actually
> used it.
Yes, this is not a optimal solution and one of the things we have
planned for a later version (not the next one) is a normal layer
system as many other packages have them.

> Rick wrote: 
> > another thing that would help with big scene slowdown, would be a
> > better method of redrawing the scene, Moray tends to overdraw the 
> > same pixel many many times (once for every object that intersects 
> > that pixel).
Yes, only the edges are drawn and if they overlap (which they always
do when there are lots of objects, they are drawn multiple times.
Checking whether the pixel has been drawn wouldn't change anything,
except slow down the redraws.

> Perhaps it would help if spheres (, cylinders, patches, etc.) wouldn't
> just always consist of the same number of lines. What if this depended
> from their actual pixel size of the screen? While big spheres could
> gain accuracy, smaller ones could be drawn with fewer lines, thus
> speeding up things a lot.
That's a good idea, but is unsuitable for the current way that the
edges are handled in Moray. This is because you could have up to four
different settings for size on screen and we'd then need four
*different* edge lists, instead of the single one we have now. This
means four-times the memory footprint.

> Hey! Even more suggestions! There will soon be enough for Moray 4, 5,
Hehe, and you haven't even seen the long list that we'd like to
implement<g>.

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

Rick wrote:
> 

> Moray would also benifit from support of other solids based render engines
> (some one mentioned BMRT) but this would ONLY be worth doing if moray could
> be as compatable with that system as it is with POVray, being able to use a
> only a subset of the target render engines capabilities would be almost
> pointless - a bit like the early polyray plugin.

I believe that the way to get compatability with other rendering engines
is through some of the newest additions to the plugin interface.  Most
notably the ability of one plugin to talk to another.

The idea here is that features of one rendering system that aren't
supported by Moray (or by POV-Ray for that matter) could be implemented
as a plugin, which would then directly talk to the plugin that is
supporting the alternate renderer.

> 
> Moray would also benifit from an overhauled patch modelling system,
> personally i find the current system a nightmare to use properly, and as
> spatch seems to be dead in the water these days maybe a merger of sorts
> would be a good idea.

I agree - polygonal modelling capabilities with conversion to
subdivision surfaces.

> object masking would be essential as well, meaning the ability from within
> moray to turn of parts of the scene, replacing them with a single large
> bounding box.

You can do that.  A nice addition to the current capability would be to
have layers.

Xander

Post a reply to this message