#VP and Penello
9 messages in this thread
Im using Penello to brush a series of images ( 1200 ) so I have two entries
in VP, first the images ( imag*.tga ) and then the Penello entry. What Ive run
into is after rendering about 450 finished files (outp*.tga ) the rendering
stops and I get CANNOT OPEN OUTP0450.tga . I cant understand why it would be
trying to open the output image instead of the source image. Ive got plenty of
free disk space. When I click on continue and render the subsequent images
there is no problem until the same thing hapens 4 or 500 images later.
Any ideas?
Thanks Ed
Edward,
Are you rendering to a root directory? c:\, d:\, e:\ …. ? If so, you should
probably change that to a sub directory. The reason being is that DOS imposes a
file limit on the root directory. It can only have 256 or 512 entries, (I
forget which for sure, but your numbers would indicate the 512 limit) as an
absolute maximum. That includes sub directory entries also. Sub directories
have no such limit, other than remaining available physical hard drive space.
That's my tip for the day!
mdawson
Thats got to be it.
Thanks a lot!
Ed
Ed, route your files to a sub-directory, not a root directory. DOS limitation
will cut you off at 512. Now it's my turn. A question: I just can't understand
why pennello did not include some sort of friskate which would allow the user
to define a hot/safe boundry. Without it I have to go through too many queue
entries and file stream control. Am I missing something there? Jeffrey
<< DOS limitation will cut you off at 512. Now it's my turn. A question: I just
can't understand why pennello did not include some sort of friskate which would
allow the user to define a hot/safe boundry. Without it I have to go through
too many queue entries and file stream control. Am I missing something there?
Thanks, youre right about the file limit. If you mean by hot/safe boundry the
ability to apply brushes to only a part of the image you are right, it would be
a great feature. Im doing a lot of brushing one set of images then using alpha
to overlay another previously brushed layer.One thing I figured out may help.
Since the brush stroke color is based on the color of one pixel under the
center of the brush stroke, it works just as well in most cases to use low res
(376×240 or even 188×120 ) source files and then use source scale to render
full size output. This saves lots of time rendering the source files and for
images that will be moderately to heavily brushed I cant tell the difference.
Ed
Ed, it would seem that a polygonal bounding box or lasso hot/safe area would
not be that complex a piece of code. Could it be they were holding off for the
{UPGRADE}! Frankly, I see that feature as indispensible… and irritates me. In
the meantime, I have been setting up FLC stand-ins. You're right about the
scale source. My guess is, now that Xaos got a sobbering look at price
structure, they will see that the 3-DS user-base is growing quickly and adjust
accordingly. [they ought to take a look at Painter 3.0 for a few feature tips.
It's a little odd – the Fractal people have a somewhat sloppy program that
needs lots of code refination, but really understand a paint interface. Whereas
the Xaos programmers are top top shelf, but could use some on-sight real
artist's input. Just like life I guess. Jeffrey
Fractal Design has John Derry on staff. He is a fine artist and has years of
experience with paint program interfaces. He worked for Time Arts as a demo
artist -etc. during the heyday of Lumena. Those folks have the longest pedigree
of paint programming experience on the planet. They aren't just guessing about
what artists' need.
-Paul
Paul, you'll get no argument from me about FDesign's understanding of what an
artist needs. I well remember the days of Lumena, which I think was $5000. I
come from a fine arts background, specifically painting, and when Painter 2.0
came out I nearly fainted. 3.0 demonstrates the fact that they know how to make
a computer a true ART STUDIO TOOL. However, <sigh> a number of code issues keep
arising. A few of the more high end programmers I know can really get to
spinning their wheels when talking about PAINTER's bizarre tendency to eat
itself, produce GPFs and demonstrate some all too obvious bugs. I'm not a
programmer, but can clearly recognize Bugville. When I was about to upgrade to
3.0, a fella that I team with said "wait just a bit, it's very buggy". In the
end, yes, Painter is perhaps the most innovative piece of 2D imaging software
out there. Question: Can this degree of image manipulation power also have
cleaner code? Hey, while I'm at it – now that X-tools are bundled with 3.0, I
hear they are working on a 3D-paint interface. WOW! watch out models, is it
real modeling or is it PAINTER <LOL> Jeffrey
Jeffrey,
I have to agree about the fragile code in Painter and I hope they can
strengthen it. At least it runs well enough to be a success and show that
programmers don't have to keep remaking the programs of the last decade.
-Paul