Rudy Velthuis wrote:
> 
> Ken schrieb in Nachricht <36E5128B.3FA05DFF@pacbell.net>...
> >Rudy Velthuis wrote:
> >
> >> Hmmm, I seem to be understood wrong again. I was not criticising anyone
> and
> >> I didn't feel I was being criticised by you either. Sorry if I gave
> anyone
> >> that expression. I was just a bit puzzled by Ken's reply.
> >
> >   Ken apologizes. He was trying to be off topically funny but
> > failed to somehow convey this in his juvenile attempt at humour.
> > Ken is a bad boy and I can assure you is in serious trouble now .
> > I will see to it that he punished severely for his crime and make
> > him promise to behave himself from now on.
> 
> Heheh. It would have even been funnier if you had signed it: -- My Mother
> 

then again... *REAL* mothers punishing *really* naughty little boys
might not bother to sign at all...

Ken?  You there Ken?  Ken!?!?!?


<snip>
-- 
Stuff for POLYRAY, some raytraced images, and
DTA can be found at:
http://www.europa.ccom/~dearmad

Post a reply to this message

Dearmad wrote:

> then again... *REAL* mothers punishing *really* naughty little boys
> might not bother to sign at all...
> 
> Ken?  You there Ken?  Ken!?!?!?

Ratboy has been chained in the cellar until this weekend. If he
behaves himself I might even feed him someting next week.

Ken's (a.k.a. Ratboy ) Mother

Post a reply to this message

Admittedly, it will be cool to see light_sources stay with any
group/CSG they're put with (would also be semi-cool to be able to
group cameras... why? consider a robot or spacecraft with cameras
physically attached to them so you can show scenes from their
perspective, or a mannekin with a camera in its head --- built 
with IK and transform limits so you can pose it as a character in
your scene, then switch cameras to "see" things from its 
perspective). 

But back to the topic at hand: until that revision, there is
a workaround if you've got a gotta-do-now type project. Three
observations:

1. Light_sources can be declared objects.
2. UDO's can point to declared objects.
3. UDO references stay put when you group or CSG with them

Just did a quickie test... seems to work. A simple, basic UDO 
to stand in for a light source is a fairly easily hand-made thing 
and transforming the UDO transforms the light_source appropriately.
Might work for you in the here and now.

(Sadly, there are limits on what you can do with a #declare'd
camera, so the same technique doesn't adapt to cameras, but it 
may to work for what you're describing...)

Charles
-- 
Fusner's Galleries - http://www.enter.net/~cfusner
"A conclusion is simply where you got tired of thinking."

Post a reply to this message

Charles wrote:
> 
> Admittedly, it will be cool to see light_sources stay with any
> group/CSG they're put with (would also be semi-cool to be able to
> group cameras... why? consider a robot or spacecraft with cameras
> physically attached to them so you can show scenes from their
> perspective, or a mannekin with a camera in its head --- built
> with IK and transform limits so you can pose it as a character in
> your scene, then switch cameras to "see" things from its
> perspective).
> 
> But back to the topic at hand: until that revision, there is
> a workaround if you've got a gotta-do-now type project. Three
> observations:
> 
> 1. Light_sources can be declared objects.
> 2. UDO's can point to declared objects.
> 3. UDO references stay put when you group or CSG with them

Yes, it does.  Just the solution I came up with after awhile too, and
yes I'll second your positive findings as working!  Thank goodness!  So
my animation is off and continiug...

> 
> Just did a quickie test... seems to work. A simple, basic UDO
> to stand in for a light source is a fairly easily hand-made thing
> and transforming the UDO transforms the light_source appropriately.
> Might work for you in the here and now.
> 
> (Sadly, there are limits on what you can do with a #declare'd
> camera, so the same technique doesn't adapt to cameras, but it
> may to work for what you're describing...)

Not that *I* care! :o)  the LIGHT problem is as good as solved- this
sort of "workaround" is nothing compared to some of the mangly band-aids
I've slapped together to keep things from falling apart as the "prject"
goes marching on... :o)

Thanks for the input, Charles.

-Peter
-- 
Stuff for POLYRAY, some raytraced images, and
DTA can be found at:
http://www.europa.ccom/~dearmad

Post a reply to this message

Yeah the below works but this brought up another -er- feature of MORAY
when exporting to POLYRAY...

it DEFINES the referenced UDO object as:

name*_REF*

between the *'s is moray's added, however when it actually CALLS the
object (3 lines later) it drops the _Ref it added so get nothing- until
you go in and hand edit the little sucker.  I discovered this after
placing about three hundred 3d letters once that were included UDO's... 
I look back laugh now, but...

hehe, it's things like this that keep this hobby alive...

Dearmad wrote:
> 
> Charles wrote:
> >
> > Admittedly, it will be cool to see light_sources stay with any
> > group/CSG they're put with (would also be semi-cool to be able to
> > group cameras... why? consider a robot or spacecraft with cameras
> > physically attached to them so you can show scenes from their
> > perspective, or a mannekin with a camera in its head --- built
> > with IK and transform limits so you can pose it as a character in
> > your scene, then switch cameras to "see" things from its
> > perspective).
> >
> > But back to the topic at hand: until that revision, there is
> > a workaround if you've got a gotta-do-now type project. Three
> > observations:
> >
> > 1. Light_sources can be declared objects.
> > 2. UDO's can point to declared objects.
> > 3. UDO references stay put when you group or CSG with them
> 
> Yes, it does.  Just the solution I came up with after awhile too, and
> yes I'll second your positive findings as working!  Thank goodness!  So
> my animation is off and continiug...
> 
> >
> > Just did a quickie test... seems to work. A simple, basic UDO
> > to stand in for a light source is a fairly easily hand-made thing
> > and transforming the UDO transforms the light_source appropriately.
> > Might work for you in the here and now.
> >
> > (Sadly, there are limits on what you can do with a #declare'd
> > camera, so the same technique doesn't adapt to cameras, but it
> > may to work for what you're describing...)
> 
> Not that *I* care! :o)  the LIGHT problem is as good as solved- this
> sort of "workaround" is nothing compared to some of the mangly band-aids
> I've slapped together to keep things from falling apart as the "prject"
> goes marching on... :o)
> 


-- 
Stuff for POLYRAY, some raytraced images, and
DTA can be found at:
http://www.europa.ccom/~dearmad

Post a reply to this message

Dearmad wrote:
> 
> -Peter
> --
> Stuff for POLYRAY, some raytraced images, and
> DTA can be found at:
> http://www.europa.ccom/~dearmad

Er, umm, ah Mr. Dearmad Sir.,

Two quick items to discuss with you.

Did you know that the link to your page is mispelled ?
.COM only needs one "C" to make it work.

  Secondly you sent me a copy of dta32 when it was brand new and right
out of the box so to speak and at the time I thought it was odd there
was no command reference for it. I stopped by your site this morning,
after debunking your bad link, to see if perhaps this oversite had
been corrected. Alas and to my dismay the package and version you have
at your site is as devoid of information as the one I have.

 Is there a reference list of possible commands available somewhere ?

 If so where might that be ?

 If not why not ?

 I get the normal quick list if I just type dta32 at the command prompt
but even the older version had that and a reference too. It seems the
two versions are not structured the same and I would like to know what
the features and capabilities of the program are so that I may evaluate
it to it's fullest extint. Without docs I con't even know where to send
registration money to if I decide to keep it. That should be motivation
enough for Mr. Mason to get at least a small doc on the subject together.

Thank you for your time Mr. Dearmad Sir..

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken, um, weren't you in the BASEMENT a littlewhile ago!  Now GET BACK IN
THERE or I'm telling MOM!

:)

<snip my embarrasin' stuff>

> 
> Er, umm, ah Mr. Dearmad Sir.,
> 
> Two quick items to discuss with you.
> 
> Did you know that the link to your page is mispelled ?
> .COM only needs one "C" to make it work.
> 
>   Secondly you sent me a copy of dta32 when it was brand new and right
> out of the box so to speak and at the time I thought it was odd there
> was no command reference for it. I stopped by your site this morning,
> after debunking your bad link, to see if perhaps this oversite had
> been corrected. Alas and to my dismay the package and version you have
> at your site is as devoid of information as the one I have.
> 
>  Is there a reference list of possible commands available somewhere ?

> 
>  I get the normal quick list if I just type dta32 at the command prompt
> but even the older version had that and a reference too. It seems the
> two versions are not structured the same and I would like to know what
> the features and capabilities of the program are so that I may evaluate
> it to it's fullest extint. Without docs I con't even know where to send
> registration money to if I decide to keep it. That should be motivation
> enough for Mr. Mason to get at least a small doc on the subject together.

hehe... I think Dave's written off the $ involved... but you're not
missing anything I have or that Dave sent me or has himself I bet.  For
DTA32 he seems to have yanked a lot of features that can be accomplished
by other simpler means or that he will add when it's out of beta
(alpha??) stage.  Might be time to bug the poor man again and see what's
up.

> 
> Thank you for your time Mr. Dearmad Sir..

Yeah yeah, get back down there <kick>.

and thanks for catching my- -er- intentional oversight trying to bug off
SPAM web browsers- you know, uh... nevermind.

--
stuff for people NOT in their basements on
rogue systems WITHOUT their MOTHER's approval
can be found at:
http://www.europa.com/~dearmad/

Post a reply to this message

I always thought of modellers as tools for ppl who thought visually rather
than in a more ordered fashion (not that visually isn't ordered). I envy the
guys that see a scene as the journey and not the destination... sorta

Lue Ebra

Rudy Velthuis wrote in message <36e3c2a8.0@news.povray.org>...
>
>Alex Magidow schrieb in Nachricht <36E342FE.D8753097@mninter.net>...
>>Dearmad wrote:
>[...]
>>> At any rate- hand attaching it isn't a problem except that the file is
>>> thousands of lines long and I need to generate hundreds of these things
>>> and yes, *I'M LAZY!*.
>
>
>>Lazy? Lazy? Just the thought of doing this stuff makes the sweat break out
>>on my brow.
>
>And modellers were made to make this kind of stuff unnnecessary, otherwise
>we could just as well hand code everything, not using Moray at all <g>.
>
>--
>Rudy Velthuis
>

Post a reply to this message

Lue Ebra schrieb in Nachricht <36e76e8a.0@news.povray.org>...
>I always thought of modellers as tools for ppl who thought visually rather
>than in a more ordered fashion (not that visually isn't ordered). I envy
the
>guys that see a scene as the journey and not the destination... sorta
>
Perhaps I didn't express myself clear enough. I meant to say, modellers,
just as most other computer programs, are (or should be) designed to make
our life easier (by taking away lot of hand-coding), not more complicated
(by introducing extra search/replace and hand-coding cycles).

--
Rudy

Post a reply to this message

Rudy Velthuis wrote:
> 
> Lue Ebra schrieb in Nachricht <36e76e8a.0@news.povray.org>...
> >I always thought of modellers as tools for ppl who thought visually rather
> >than in a more ordered fashion (not that visually isn't ordered). I envy
> the
> >guys that see a scene as the journey and not the destination... sorta
> >
> Perhaps I didn't express myself clear enough. I meant to say, modellers,
> just as most other computer programs, are (or should be) designed to make
> our life easier (by taking away lot of hand-coding), not more complicated
> (by introducing extra search/replace and hand-coding cycles).

For myself I used to be a pure handcoder and loved the challenge, but
slowly I let Moray seep into my toolbox and soon I found my projects
took off but I was *still* mortally challenged to get the scenes out-
for me the bar just got raised when I made it "easier" for myself by
using a modeller.  I'm on frame 4137 (gotta rerender the last 61 as I
misplaced a light... grrr) of a 17fps cartoon now (it'll be about 10,200
in length) and there is no way on god's green earth I'd have attempted
it without a tool similar to Moray.

But, let me add this: I wouldn't trade in my handcoding days of
struggling for example to apply texture maps juuuust so for anything,
because now when I want to go in and add an "eyeblink" or something I
understand precisely where to go and how to apply the transformations
and in *what order* and why this is the way it works.  And the knowledge
handcoding has given me for *really* tweeking a texture is invaluable. 
Knowing the guts, as it were, has been a great benefit to me, or at
least the projects I throw in my direction.

hehe... but I always feel a twinge of sympathetic pain when I see a
newbie starting out with raytracing.  It's a rough road and for me took
years to get even moderately skilled.

-- 
Stuff for POLYRAY, some raytraced images, and
DTA can be found at:
http://www.europa.com/~dearmad

Post a reply to this message