It was a dark and stormy night.

[markw]

Trying to modify the lighting to get rid of the gloom

 

I've hit something that has me completely flummoxed.

 

I modified the overhead light position as in this screenshot

 

Went to camera view to do a test render and got almost complete gloom. So went back to check position in top view, to find this

 

 

The apparent position had changed completely, going by the highlighted section in the window BUT, the position numbers in the properties section show no change ?

 

I thought I'd made a mistake so tried to correct it, several times. Each time the place changed without me doing so and each time it went to different position, Top left, Bottom left, Bottom right... Am I missing something obvious here ?

 

I should add that, each time I go to correct the changed position. I click to move it and, the slightest change makes it appear in the correct place, even though the pointer has only moved maybe 1 cm or less. Tested that position in the camera view, only to get another, different, change !

 

Should I go for a fresh install from the CD ?

 

V15J OSX 10.68

 

regards

simon

 

 

Here is the project file with all except the wave sequence included.

Wet_Day_02.prj

Hi Simon,

Not sure if this is good news or bad, but I've just tried your project in 15j+ up to v17 on my Mac and I get no problems with the positions of the lights. They stay where I leave them.

Maybe just try restarting the Mac and/or resetting AM first before doing a fresh install.

[NancyGormezano]

The apparent position had changed completely, going by the highlighted section in the window BUT, the position numbers in the properties section show no change ?

 

I thought I'd made a mistake so tried to correct it, several times. Each time the place changed without me doing so and each time it went to different position, Top left, Bottom left, Bottom right... Am I missing something obvious here ?

 

I should add that, each time I go to correct the changed position. I click to move it and, the slightest change makes it appear in the correct place, even though the pointer has only moved maybe 1 cm or less. Tested that position in the camera view, only to get another, different, change !

 

Should I go for a fresh install from the CD ?

 

V15J OSX 10.68

 

I'm not sure what's going on with your changing position, but it could just be a screen refresh problem...??

 

I have never ever in the 12 years I've been a user, needed to reinstall the same version of A:M (any version) in order to fix something that appears broken. At most, I will close down and reopen A:M and things will work better (then it's a bug). If it's still not right, then restarting OS and reopening A:M might help (I've rarely done that - could be a problem with leaky memory - A:M bug, graphics card). Most times, it's usually something dumb I've done, a corrupted project/chor/model file or a bug. Others may have found that Help/reset settings works (because they've monkeyed too much with defaults)

 

However, after looking at your project - I have discovered a couple of things (tested in 16b and 17)

 

1) I left your Overhead light in the same position but increased intensity to 1000%

 

2) I noticed that for some reason Toon render was set to on? (may have been something I did?) - so turned it off, and I decreased your resolution to 480 x 270 for testing purposes only. Turned OFF alpha buffer, and made only render frame 0 to a PNG

 

3) in Ver17 32 bit: tried it with Multipass = OFF - looks goodish

4) tried with multipass = On - 5 pass - UGH - I see now what you mean about darkening

5) tried again with multipass = OFF - still Ugh??? why? should have been good

6) could only get it to render correctly again with multi off - by toggling the shadows ON/Off/ON for the overhead light - then it would rerender correctly

 

I haven't reduced your project to bare minimum (nor tried a new project), but my original guess is there is a bug with bulb lighting and rendering with multipass, or else there is something corrupted in your file

Edited August 24, 2012 by NancyGormezano

[Simon Edmondson]

Rob, Mark Nancy.

Thank you very much for your comments and especially the mov file ( I'm just about to watch it ). I will try the reboot restart suggestions.I don't know if its relevant but, there have been a lot of the Mac freezeouts the past couple of days. Very noticeable yesterday when I posted the sample files in the morning .

 

I had originally done them as tga files then remembered the jpg convention for the forum so started to redo them. It seemed like every other render was balked by the freeze ( the one where you have to hide then reopen AM ). Normally it only happens once a day or so...

 

Thank you all for your help.

regards

simon

[Simon Edmondson]

With big thank you's to Rob for the movie and Nancy for her help, I redid the lighting with the following result.

The reboot and relaunch of the program seemed to work ( without a fresh install ) and the movie helped greatly with the understanding.

Going to work on the walk this weekend.I realised as I was about to go to sleep what was needed. .. in theory anyway!

regards

simon

 

Scene_Four.mov

[NancyGormezano]

Well Simon...Turns out I can recreate your phantom moving bulb light. In ver 17 32 bit.

 

I found out that if I render your scene with Multipass = OFF, that afterwards your overhead bulb light behaves as it should, ie it's position has NOT changed. (evident from top view)

 

However I found out also that if I change the rendering properties for the next render, ie render with 5 pass, that after the render, the bulb will have moved, even though the position data says it did not, and that any render done after that will use this new phantom position. Which is why my 2nd render with MP = OFF did not look the same as it did as the first time I did MP = OFF (image in this post). I had done 1) MP=OFF 2)MP=ON 3)MP=OFF (which used the new bad light position from 2nd render)

 

I also found out that the position for the bulb light would change differently depending on the number of passes. 9 pass would end up with a different position than 16 pass, and different from 25 pass, which of course would render wildly different lighting results based on number of passes (shouldn't be all that different).

 

The main way to have it go back to the original position was to delete the project (or chor), and reopen it, and the position of the bulb light would go back to original. I'm not sure if toggling something (like shadows on/off) would make it go back to original position (did not try).

 

Hard to debug lighting with this situation. So for now, I would say you might want to render/debug lighting with multipass OFF if you are still experiencing difficulty. I think this is only a bug with bulb type lights. I haven't tested with kliegs or sun type lights (ie, haven't ever noticed this before)

 

Your animation is coming along, and we now see why you may have wanted it to be dimly lit at first. Did you mean for the new light to come on that slow? That's a little odd, but perhaps you have a reason?

 

EDIT: Submitted bug report

Edited August 25, 2012 by NancyGormezano

[Simon Edmondson]

Your animation is coming along, and we now see why you may have wanted it to be dimly lit at first. Did you mean for the new light to come on that slow? That's a little odd, but perhaps you have a reason?

EDIT: Submitted bug report

 

Nancy

 

Thank you very much for your post. I wonder sometimes whether it is my lack of knowledge that causes such things so, your confirmation is a relief that I'm not going quite as doolally as feared. I think its time to move up to V17 64 bit, I need to get some other things out the way first.

 

The slow light is supposed to be a sunray type light. Its been awhile since I've seen or used one but, my memory of them is that they come on, then warm up to operating temperature and thats the effect I was going for. I was a bit bothered by the artefact that appeared at 05:05 and lasted a few frames but, I can touch those out later on.

regards

simon

[Simon Edmondson]

Changed the timing on the sun ray type lamp and the walk sequence of the figure.

 

Scene_Four_B.mov

 

I had a recurrence of the darkening problem this morning when trying it out.

I changed the bulb light for a rim light, in the same position with the same settings.

It suffered from the same problem with the position changing when it came to render .

Also the light was initially very large and difficult to set correctly.

In the end I deleted it and replaced with a new one. That came in at the standard size.

 

It made me wonder if my initial error with the scale of the bulb light ( it was set too large ), was a contributory factor in the changing position problem ?

regards

simon

[NancyGormezano]

It made me wonder if my initial error with the scale of the bulb light ( it was set too large ), was a contributory factor in the changing position problem ?

 

Yes, all light types are jittered when rendering with multipass ON. However, if the light is large, the position change will be most noticeable. It is less noticeable with small lights. (This is also true for the camera and DOF).

 

I submitted a bug report, and Steffen said this has been in all versions since 11, or that's as far back as he tested.

 

Currently, the biggest problem is that the position of the light isn't automatically reset back to it's original position, after the multipass render, and with large lights, you will get wildly different results, also depending on number of passes. Currently one can manually reset the position by advancing to next frame, and then back, or trying to grab the light in the window, or some other toggling (shadows on/off/on maybe, not sure?), if you want to retest the lighting with other values for that frame. Or you can render with multipass OFF (lights are not jittered).

 

I believe Steffen said this will be fixed in the next version of 17, but I'm not sure if I understood correctly.

 

He is also considering implementing a jitter % for lights when using multipass. Currently the default is 100%, but eventually one could set the jitter percent to 0%. If the jitter is set to 0, then the shadows could look the same or closer to those rendered with multipass OFF, I believe. At 100% they look the softest (as now). I'm not sure if he has decided to implement this.

[Simon Edmondson]

Nancy

 

Thank you for the info and the update on the possible fix. I'd wondered about the softening effect and, it makes sense that the lights would jitter slightly to get that result. When I first started with 3D CG i used to like the film noir approach of hard strong shadows, and its still a look I love but, as my knowledge has slowly improved, I like more variety now. Theres a thread elsewhere about 64bit for Macs, that sounds like something I would like to use...

reg

Thanks for your help

regards

simon

[NancyGormezano]

Thank you for the info and the update on the possible fix.

 

I have received notice that the jitter % property will be implemented in next release of 17, and that positioning of lights will be fixed. Thanks Steffen!

[Simon Edmondson]

Here is a wireframe of scene Five.

Apologies for the delay, The dentist and other things have intervened.

Any feedback welcome.

regards

simon

 

Ps

the feet do lift and tilt, honest !,,

It doesn't show so well in the wireframe.

 

I've just spotted that the turn stop is too sudden before it sits down ( the drink would slosh out ! )

I will correct that and any other points raised, tomorrow.

 

Scene_Five_Wire.mov

[steve392]

Yea that looks prety good to me

[Gerry]

That's nice progress Simon. All I would say is to see if you can get his turn a little smoother, so he's not coming to a complete stop, then turning, then sitting. The stop is a little robotic. (Unless he's a robot! I don't think that's come up yet!)

[Simon Edmondson]

That's nice progress Simon. All I would say is to see if you can get his turn a little smoother, so he's not coming to a complete stop, then turning, then sitting. The stop is a little robotic. (Unless he's a robot! I don't think that's come up yet!)

 

 

Gerry

Thank you. I've revised the turn this morning and hope its improved, less robotic. I was using the turn handles on the bones before and went back and tried that again at first but, this version was corrected using the rotate values in the properties section.

 

Scene_Five_Wire.mov

 

I was reading somewhere the other day that one of the biggest mistakes beginners make, is to make their movements too big, and suspect I may be guilty of just that.

 

regards

simon

[robcat2075]

I'm wondering what it is that you are doing that is causing this very jittery, halting motion as he walks. As I frame thru it there's a spot where the hips actually stop and move backwards a hair even though he's in the middle of walking forward. that can't be right.In general the up and down motion fo the hips seems not to be placed right in the context of the walk motion.

 

His feet are still shuffling parallel to the ground. That will always look odd. You really HAVE to lift the ankles off the ground.

 

In that first set of videos i pointed you to there is some live action that I motion track with dots. Even though the toe of the foot barely clears the ground as it is carried forward, the ankle is clearly lifted up in an arc from footstep to footstep.

 

If you want to send me this project I'll take a look at it.

[Simon Edmondson]

..

His feet are still shuffling parallel to the ground. That will always look odd. You really HAVE to lift the ankles off the ground.

 

In that first set of videos i pointed you to there is some live action that I motion track with dots. Even though the toe of the foot barely clears the ground as it is carried forward, the ankle is clearly lifted up in an arc from footstep to footstep.

 

If you want to send me this project I'll take a look at it.

 

Robert

Thank you for the feedback.

I will look at it again this afternoon, I'm a little reluctant to take up more of your time than I have already but thank you very much for the offer.

The jitter is not apparent in the orthogonal views when I play it through, though I will check again, perhaps because those cameras are constrained to the Body Null ? That causes trouble when using the orthogonal's and the null is rotated. The whole thing tips over too in a way that is difficult to control.

regards

simon

 

Ps

On a trivial note:

The Orthogonal's sounds like on of the challenges in "Jason and the Argonauts" !

[robcat2075]

The jitter is not apparent in the orthogonal views when I play it through, though I will check again, perhaps because those cameras are constrained to the Body Null ? That causes trouble when using the orthogonal's and the null is rotated. The whole thing tips over too in a way that is difficult to control.

 

This isn't a camera problem, it's body motion problem. Something basic is wrong and we need to find out.

[Simon Edmondson]

Updated.

 

Here is the movement from the side camera.

 

Side_Wire.mov

 

Here is the same movement from the perspective camera.

 

Scene_Wire.mov

 

 

Simon

[robcat2075]

I would recommend not to animate via a camera constrained to a character. We do that occasionally with face cams but even that is secondary to the view the camera sees.

 

If you are trying to manipulate a character while you are looking through a camera that is constrained to the character you are creating a feedback loop that will never be manageable. It is making your task 100x harder than it needs to be. It's like trying to move a table while you are standing on the table.

 

You can put cameras anywhere you want, as many as you want, but don't attach them to the character.

 

Send me that PRj and I will look at it.

[Fuchur]

I would recommend not to animate via a camera constrained to a character. We do that occasionally with face cams but even that is secondary to the view the camera sees.

 

If you are trying to manipulate a character while you are looking through a camera that is constrained to the character you are creating a feedback loop that will never be manageable. It is making your task 100x harder than it needs to be. It's like trying to move a table while you are standing on the table.

 

 

You can put cameras anywhere you want, as many as you want, but don't attach them to the character.

 

Send me that PRj and I will look at it.

 

there are exceptions of that rule... facial animation especially lip synchronisation can be jelpful with that... yes i see that it is aliitle against "make it look good when u see it and only from that perspektiv but if you change something later on it can be tricky...

 

see u

*fuchur*

[markw]

Updated.

 

Here is the movement from the side camera.

 

Side_Wire.mov

 

Here is the same movement from the perspective camera.

 

Scene_Wire.mov

 

 

Simon

Some of that body jitter seems to me because as one leg comes up, moves forward and then hits the ground the body dips forward and back twice in that one step. Most evident in the side view, with the constrained camera, giving a rather rapid woodpecker like motion to the upper body.

When seen in perspective from the other camera, because of the speed of those dips forward, it makes the body seem to jitter.

 

The constrained camera was my suggestion Rob, sorry!

But I have found it helpful at times to have but would agree it would be very difficult to do all the animating from a constrained camera. Mostly I'm in Birdseye View in the Chor and the camera that I render from always has the final say.

Forgive me Simon I maybe should have been clearer in the other thread where you asked.

[Simon Edmondson]

Send me that PRj and I will look at it.

 

Robert

 

Thank you once again for your kind offer. I don't mean to be rude but, pardon me if I don't send it at this stage. Perhaps later if I don't crack it myself.

 

I'll try constraining the cameras to a null and move that with the character.

Steep learning curve so far but, worth it in the end. Hope so anyway.

 

Mark

No need to apologise at all. It was a good idea just needs adjustment.

Thank you.

regards

simon

[robcat2075]

I'll try constraining the cameras to a null and move that with the character.

 

Don't do that at all. Animate to a stationary camera. You don't need the camera to move to animate this shot. Moving the camera is causing trouble.

[Rodney]

Following Robert's advice is wise and I won't go deeply into exceptions to the rule but I will offer the following for the inevitable point in the future where someone offers (seemingly) contradictory advice. I believe the important point to understand is that you want to animate to the 'rendering camera' wherever and whenever possible. An incredible amount of time can be wasted animating to the wrong camera and it gets confusing when you have multiple cameras and aren't sure which are 'helpers' and which are your rendering cameras. It also increases the chances that you will accidentally animate something that you've perfected while in the wrong camera!

 

The main reason to add a Camera to any character would be to set up a shot that captures the precise point of view of one or many characters.

For this you could constrain the Camera to the Character but... it'd be as effective to add the Camera directly to the Model (and you wouldn't have to worry about the Contraints at any time). In A:M, Cameras and Lights that are added to a Model are treated as Bones for the purpose of adding them into Models so you access them via Bones Mode in the Modeling window. An example of this would be placing the Camera at the position of one of the Character's eyes or slightly behind the Character for a continuous over-the-shoulder shot. Wherever the Characters goes so goes the embedded Camera and/or Light.

 

File this away as potentially useful information for later down the line... but... not for this shot!

[Simon Edmondson]

...

File this away as potentially useful information for later down the line... but... not for this shot!

 

Rodney

The POV idea would be very useful for the next one planned but, as you suggest, I'll not try it with this one.

I followed Roberts pose to pose tutorials and tried to set up a walk cycle to try that. I won't use a cycle in the end but it was good to do to find out where the errors may have been before.

 

There was a glitch setting up the action as, for some reason, it wouldn't allow me to play the cycle through using the buttons at the bottom of the view but, when I switched to the chor that option was available.

 

I think the reason the figure jittered before may have been because I had over keyed the movements in the back and shoulders and the program was having to cope with that. You live ( and hope to ) learn.

 

Scene_Five_Wire_C.mov

 

I will have another go at doing the walk freeform ( as it were ) tomorrow. Its getting to be like drafting a script, albeit more rewarding.

regards

simon

[Simon Edmondson]

Take four.

 

( I hope ) the jitter has gone.

If so, it was almost certainly due to me overkeying the back movements. There were keys at four points in each step and the movements at each point were too large. Perhaps gone too far the other way this time , not sure ?

Getting there very slowly. Thank you all for your patience and help.

regards

simon

 

Scene_Five_D_Wire.mov

[Rodney]

I see a marked improvement over the last render.

The movement is considerably smoother.

 

I'll save any nitipicking for a shaded render... gah... okay... no I won't.

This is just an impression so take it for what it's worth.

Take a moment to view the timeline/channel for the character's right foot and see if it doesn't look like it's slipping outward to you.

I wouldn't even comment on it but it seems important that when the characters weight is put on that foot at the very end of this sequence it stays put. It'd be okay to move thereafter but not before the character has a chance to shift weight a little. Now if in shaded/rendered view that foot is just squishing down (which would indicate more weight being place on that foot) that'll be okay, but that's not what appears to be happening in this wireframe view.

[markw]

That's looking much better now.

Yes, still more tweaking to be done but its getting there.

Maybe look at the feat next as there's still some slipping going on and look at the hip null too. Hard to tell in wire-frame at that angle but it looks like it stops moving forward at one point (I could be wrong) but it shouldn't, in a normal walk it should always be moving forward.

[Simon Edmondson]

I rendered out a full version but the lighting looked wrong.

So I went back and tried to adjust it to get the 'correct' settings.

 

When rendered to jpg format I get this result

 

 

When rendered to png format, this is the result.

 

 

Tried it with .tga and open EXR but the results were very similar to the png. Although EXR looked a lot brighter when they were opened in photoshop.

The QT file was closer to the jpg in result. Which was good for the sun ray lamp and the shadows on the wall but not under the beach lounger or the figure.

 

Is it because the other formats has an alpha channel and jpg does not ?

regards

simon

[Rodney]

Is it because the other formats has an alpha channel and jpg does not ?

 

This should not effect your imagery in any significant way.

The Alpha Channel is simply a mask that specifies transparent areas.

JPG is RedGreenBlue(RGB) and the others RedGreenBlueAlpha(RGBA).

A RGBA image rendered with no masking in the alpha channel should render the same as RGB.

 

Of course if you aren't wanting anything to be transparent you should turn the setting for Alpha Channels Off in your Camera/Rendering settings.

The main reason to turn it off is that you don't need it.

 

If there is a problem with regard to Alpha Channels rendering geometry and lighting differently you might have identified a bug in rendering RGBA.

 

 

P.S. Other than the issues you are having... very nice rendering!

[Simon Edmondson]

Of course if you aren't wanting anything to be transparent you should turn the setting for Alpha Channels Off in your Camera/Rendering settings.

The main reason to turn it off is that you don't need it.

 

If there is a problem with regard to Alpha Channels rendering geometry and lighting differently you might have identified a bug in rendering RGBA.

 

Rodney

Thank you for your reply.

What I was after was the glow effect of the jpg image.

The png loses some of that and gains that dark rim to the light cone.

we discussed the merits of rendering to different image formats earlier. I think perhaps I should render a sequence to png then save as afterwards. ( its a good excuse to get out the house and watch people walking down the sea front while its rendering away ! ).

 

Off for an ice cream...

regards

simon

[Simon Edmondson]

I was preparing the whole project for rendering and tried out the png and EXR formats as suggested above.

This is the result as a straight Jpg

 

 

But, when I go to png, I get this

 

 

And EXR gives me this. Sorry I can't upload that.

 

I only have Photoshop CS2 and, when opening the png and EXR frames the alpha is there but I can't access it or the other layers. The EXR is notably different to all the other file types in the result it gives. It is a lot lighter in appearance and looks like its waiting to be adjusted but... how ?

 

You may gather, accurately, that I am not very conversant with PNG and EXR formats.

Any help gratefully received. Thank you very much.

regards

simon

 

I should add; the only change from render to render was in the file formats used. No other settings were changed.

[NancyGormezano]

Exr is this weird format that anybody can define how to interpret. The format from A:M requires plugins (I believe?) to be used in PS, aftereffects, or it did at one time.

 

The way to manipulate A:M exr files is via composite in A:M.

Is that png image coming directly from A:M?or are you bringing it into PS and saving from there? It looks like it got saved as "interlaced"?

 

Did you try turning OFF alpha for the png (do that) ? Are you rendering with multipass ON (don't do that)? and trying to switch between jpg, png and exr? Remember there's still a bug in your version - unless you tried 17a (do that)?

 

Make a simple chor with just the transparent/reflective window, and your lighting setup, model to reflect in window, and rendering setup. Render 1 frame. There may or may not be a bug, but a simple project would be needed to send to A:M reports if so.

 

 

EDIT: AND I might add version 17 has added the ability to save individual files for each of the buffer types (depth, shadows, ambiance, diffuse, specular, etc) for the image types png, tga, jpg. No need to fool with exr anymore in PS, AE, etc - whoooo hoooo! And they can be used in A:M composite as well! Muy bueno!

 

EDIT2: I just tried rendering to png with 1) alpha OFF and 2) alpha ON (vers 17). Transparency for the window in the final render cannot be computed correctly when there is no background model (must take into account color, intensity of background). I also downloaded your png file - it definitely was rendered with alpha ON. Turn alpha OFF for your pngs, or put in some dome model for the background. Leave alpha = ON if you intend to add a background in post (aftereffects, PS)

Edited September 12, 2012 by NancyGormezano

[Simon Edmondson]

Nancy

Thank you once again for your comprehensive explanation and help. Much appreciated.

I'm just gearing up to start rendering the whole lot so that will be a lot of help.

I've learnt a lot doing this project. Far more than I expected to, but all of it worthwhile.

Regards

simon

[Rodney]

Simon,

Have you downloaded and installed the latest release (v17a)?

 

There is at least one report of a fix related to lights that may address the changes you are seeing. (I'm a bit doubtful on this but it might make the difference)

When in doubt you can always install the new release into a new folder (and not install over the top of the previous version). Then you can then have access to v17 and v17a.

[Simon Edmondson]

Simon,

Have you downloaded and installed the latest release (v17a)?

 

There is at least one report of a fix related to lights that may address the changes you are seeing. (I'm a bit doubtful on this but it might make the difference)

When in doubt you can always install the new release into a new folder (and not install over the top of the previous version). Then you can then have access to v17 and v17a.

 

Rodney

 

I fully intend to but, I haven't bought V17 yet. There was some debate elsewhere about the 64 bit version for Macs not being available yet (?) and, domestic finances and dental bills aside, I'm waiting for that.

 

When I rendered a sequence of png frames. then "Saved Animation As" within AM, it seemed to come out as I expected. It only seems darker on the single, individual frames ?

regards

simon

[Rodney]

Rodney

 

I fully intend to but, I haven't bought V17 yet. There was some debate elsewhere about the 64 bit version for Macs not being available yet (?) and, domestic finances and dental bills aside, I'm waiting for that.

 

When I rendered a sequence of png frames. then "Saved Animation As" within AM, it seemed to come out as I expected. It only seems darker on the single, individual frames ?

regards

simon

 

Sorry. It's hard to keep track of who has what. That is the real benefit to subscribing to A:M.

Everyone can be on the same page.

 

If you go into your profile there is a place where you can enter your version number and that will automatically clue everyone in.

Then folks like me don't make stupid suggestions that don't apply to you.

 

For the record: I want you to upgrade but I don't care if you upgrade. If that makes any sense.

Most of all I just want you to get the most out of using A:M.

 

When I rendered a sequence of png frames. then "Saved Animation As" within AM, it seemed to come out as I expected. It only seems darker on the single, individual frames ?

 

Barring minor changes due to translation of image formats the Save As Animation process just transfers what is there in the original rendering to the new format. So the darkness on single frames should be there in the original render. Perhaps some day we might see a Color Correction Post Effect that would remove such things (or some genius could figure out how to do that with the current Post Effects) but look to what drove the original render for the fix. (I understand that is exactly what you've been doing).

 

If using the Save As Animation process is creating that change please report it to A:M Reports because it should never do that.

 

Let me address this in a bit more detail:

I haven't bought V17 yet. There was some debate elsewhere about the 64 bit version for Macs not being available yet (?) and, domestic finances and dental bills aside, I'm waiting for that.

 

There isn't any debate about the 64bit version for Macs. Steffen clarified that. Due to the extensive coding required a full 64 bit A:M for the Mac is quite a ways away. By all reports 32bit on the Mac is running great.

 

Regarding the bills, I hear you. I'm in between jobs right now and if I had to resubscribe today that'd be difficult. But where it comes to A:M subs I've learned I cannot do without the latest and greatest so I plan a year ahead.

[Simon Edmondson]

Heres the first pass at the opening scene/Title

 

I haven't animated the hands beyond positioning at this point.

Any feedback would be very welcome.

regards

simon

 

Credits.mov

[Rodney]

Hi Simon,

It looks like you are heading in the right direction.

Here are a couple things that I would focus on:

 

While I assume there is an intended disorienting feeling going on in this scene it's not immediately apparent what we are seeing. The windshield wipers clue us in that we are seeing out the front of a car window. This might be a great place to use A:M's ability to overlay the foreground over the background. In other words, you are dealing with three main levels/layers already within this scene so you might as well take advantage of them.

 

Level 1: Inside the car

Level 2: The threshold (window) Because of where the title text is this is where the initial focus will be.

Level 3: The (unknown) road beyond

 

By separating these into those three elements and working on each with the goal to draw attention to the title will make for utter clarity despite the chaos in the scene.

 

Level three is where I think you can bring the most to this because even a few foggy elements moving in the scene will further suggest that this is a car moving through a dark and stormy night.

 

Perhaps it is at Level 3 that the title text should be?

As it is right now the title is a bit too hard to read.

 

It's a bit hard to just this shot out of context but that is my first impression.

You've got a great setup here now concentrate on the clarity in how it reads.

 

Added: You don't have to actually composite layers in order to have these three levels in your scene but it might help in making it easier to work with.

[Simon Edmondson]

Rodney

 

Thank you for your feedback, much appreciated.

I was just thinking of putting the title on a road sign outside the car when I read your suggestions. I shall try that this afternoon.

 

I like the way the title appears and disappears but, as you say, it lacks clarity that way so revision awaits.

regards

simon

 

Ps

Looking for signs I could get font styles off I saw this. It might amuse ?

[Simon Edmondson]

Updated opening , retains title position but has roadside sign.

Any comments welcome.

regards

simon

 

Credits.mov

[NancyGormezano]

hmmm..the title seems too difficult to read - probably because 1) not on screen long enough, and 2) the placement in lower left half causes confusion for viewer by the passing road sign combined with flickering lightning. Makes me want to read the sign, which also goes by too fast.

 

Anytime you have text, and make it difficult to read, it will distract the viewer from the flow of your story.

 

I even question having the title show on this sequence. Too much movement going on. I like the road sign going by, as well as the lightning. Have this as your opening, and then maybe cut to another sequence, with just the title (against black only) or against another scene with less movement going on.

 

Or if you really want title on this scene, maybe move title to center upper half of screen. Have it stay on but perhaps fade in and slowly enlarge, then eventually fade out (2-3 seconds for title sequence?), with less stuff passing by as the title is on screen.

[Simon Edmondson]

hmmm..the title seems too difficult to read - probably because 1) not on screen long enough, and 2) the placement in lower left half causes confusion for viewer by the passing road sign combined with flickering lightning. Makes me want to read the sign, which also goes by too fast.

 

Anytime you have text, and make it difficult to read, it will distract the viewer from the flow of your story.

 

I even question having the title show on this sequence. Too much movement going on. I like the road sign going by, as well as the lightning. Have this as your opening, and then maybe cut to another sequence, with just the title (against black only) or against another scene with less movement going on.

 

Or if you really want title on this scene, maybe move title to center upper half of screen. Have it stay on but perhaps fade in and slowly enlarge, then eventually fade out (2-3 seconds for title sequence?), with less stuff passing by as the title is on screen.

 

Nancy

 

Thank you for your feedback.I shall take out the title and intercut them instead with a different setup. The road sign went by a lot slower at first but it made it look as if the car was doing 5mph, appropriate perhaps given the rain, but looked a bit slow.

 

I was hoping to have this done this week but may get delayed with visiting family. The sound design is going to be another problem altogether!

regards

simon

[Simon Edmondson]

Update on the sequences

 

Revised version of the car traveling,

 

Credits.mov

 

 

New one of the title

 

Titles.mov

 

Any feedback welcome

regards

simon

[Simon Edmondson]

Following an earlier suggestion about using png files rather than tga. I rendered out the sequences that way.

I've now got to editing the frames into the final piece. However, the png results seem to be far different from what I was expecting.

 

When I open the frames in CS2 the alpha channel shows up but I can't seem to access it or the other information in the frame. Can anyone kindly give me a quick overview as to how to go about it, or point me in the direction of a resource that deals with it ?

regards

simon

 

 

[Rodney]

Following an earlier suggestion about using png files rather than tga. I rendered out the sequences that way.

I've now got to editing the frames into the final piece. However, the png results seem to be far different from what I was expecting.

 

The primary reason to use PNG is... to display the images with transparency on the internet.

Otherwise you'll find TGA to be more robust.

Once rendered to TGA it's a pretty simple matter to zap those out to PNG as well.

 

People have such confusion with the various formats that I've considered trying to put together some form of demonstration about image formats but I'm not sure even that will resolve the dilemma.

 

For my own part I am moving toward this:

TGA (The tried and true rendering format)

EXR (The way of the future)

PNG (For internet use)

 

Where possible I am hoping to forego all 'image formats' entirely and move to reviewing scenes in A:M using realtime spline tech alone.

 

Movie files (all formats are optional and some more robust than other for specific targeted viewers) but .MOV is the best for use in the forum. This is complicated by the fact that Apple has moved away from the format and doesn't support it for 64bit)

 

Way back when I made a suggestion that A:M always render to the same files every time but the reference I used was too obscure and people are so locked in to the current paradigm of rendering they got confused. I'm even more convinced than ever that A:M should (behind the scenes) always render to the same format (probably EXR first, then (in parallel) to PNG for a small thumbnail preview, then convert the EXRs to TGA... then branch out to other formats based on user specified input. The render panel would show all options in one view and the user would toggle on the ones they wanted and the user could override the default rendering order. If left alone A:M would render to every format in every size with every option (i.e. maximum waste but lots of product produced). In other words, the A:M renderer would never (completely) stop rendering as it would always have something in the rendering cue and if it were to ever run out of things to do it would begin renderering based on what you most commonly use. There is a lot more to it than this but we can't get beyond the initial steps necessary to even move in that direction.

[Simon Edmondson]

For my own part I am moving toward this:

TGA (The tried and true rendering format)

EXR (The way of the future)

PNG (For internet use)

 

Rodney

 

Thank you for your help. I did render to TGA in the past and possibly will again in future. I get bad trouble with banding when I output to Mov format and wondered if you have a preferred codec and compressor?

I bought Final Cut Pro a couple of years ago and have been using that to edit the shorts but, the compressor option within it doesn't work ( which says a lot for Apple's coding, but thats another matter ! ). I'm outputting to HD1080 resolution.

regards

simon

Ps

Just found out that, with the same settings, only the file type changed, TGA's render out about 33% faster than png files.. 4:08 as opposed to 6:30.

 

Ps2

I just reread Nancy's observations earlier. Drat !

Apologies for not taking it in, My mistake.. Have to learn how to use composite now...

[Simon Edmondson]

Heres the first rough draft of the beast.

The sound is not done yet and a couple of the transitions need more work.

Any feedback welcome.

It was supposed to only take a week. Perhaps one of the longest seven days I've worked still, I've learnt a lot doing it.

 

One curious thing in doing the assembly edit.

When trying to use some png files in the edit, even though rendered at the same 1080 res they came out with a very thick black border as though rendered at a lower res. I'll see if I can post an example later.

 

regards

simon

 

Rough.mov

 

Ps

Edited in Final Cut Pro

[Rodney]

Well, I just spent about 30 minutes writing a post only to fat finger and lose the whole thing... it's just as well I guess.

 

To summarize what I typed:

 

- The Trees look too perfectly aligned (I made some suggestions here)

- It's not clear how the drapes are closing (I make some suggestions here)

- Is this bikini clad character the same guy/gal or a new character? (I was/am confused here)

Added: I have no idea what the connection is between the car driving and the house shots are. It appears to me that someone has driven 5 miles closer to the house where we are watching the girl. It seems to me that in order for this to really sink in... assuming that is the intention... there needs to be a minimum of three beats. That is to say that we should be seeing the driver driving between every cut during the house scenes. Not all would have to have signs in them. The driver might be passing a bridge or turning off from a highway or moving from highway to asphalt to rock strewn roadway...

 

All three of these areas have a lot to do with clarity and appeal and I'd love to discuss these areas in light of your current sequence at length.

 

If confusion is the goal then I'll suggest abstracting the look of the short even further and perhaps even going with a toon-like rendering.

[Simon Edmondson]

Well, I just spent about 30 minutes writing a post only to fat finger and lose the whole thing... it's just as well I guess.

 

To summarize what I typed:

 

- The Trees look too perfectly aligned (I made some suggestions here)

- It's not clear how the drapes are closing (I make some suggestions here)

- Is this bikini clad character the same guy/gal or a new character? (I was/am confused here)

 

All three of these areas have a lot to do with clarity and appeal and I'd love to discuss these areas in light of your current sequence at length.

 

If confusion is the goal then I'll suggest abstracting the look of the short even further and perhaps even going with a toon-like rendering.

 

Rodney

Thank you for your reply.

The idea was that the female was waiting for the person in the car driving towards the town.

She gets fed up of the wait and the storm, decides to "slip into something comfortable" and relax under the sun ray lamp, while sitting on the beach with a drink.

The storm really kicks off and the power gets cut.

Person in car is still some distance away...

Modern life ( joke )

 

The idea with the curtains/drapes was simply that they would be powered. I'll get the sound put on the final version. I figured anyone who could afford a TV that size would probably have powered curtains !

 

Regards

simon