#VistaPro
46 messages in this thread
>then GIF -> DXF with a shareware program and then into 3DS
I think I've used this shareware program before — but due to the
way it wrote the face normals (or something like that — I'm NOT a
3DS expert) you couldn't "see" the faces in the Keyframer (you could
in the 3D design, however) so you really couldn't do paths, etc.
>In my case, I'll be (am) using the exported DXF to POSITION my 3DS work
exactly >into the landscape, then throw away the terrain in 3DS and Video Post
the VP >animation with the 3DS one
Now this sounds more like it — no need to have the object there during
drawing (that's what I'd buy VP for) as long as I could have it (and see it)
during keyframing my 3D stuff. You talk as if you are using a beta of VP4 —
is that correct? Are the files really as huge as John says they are? Even
importing a file for temp keyframing use that big would be daunting — not
to mention disk space.
>face normals … couldn't "see" the faces in the Keyframer<
Ah, yes, I recall this problem. Didn't realize you were the same person. I
still don't understand why you have trouble with this, I have never. I've even
done fly throughs, though they're not as easy to make striking, visually, as in
VP.
VP4 does make files as large as expected. However, one has the ability to draw
a box and export only what's in the box as a DXF. To take an entire DEM into
3DS would make it s – l – o – w, I think. <g>
DT
Mike,
>>GIFDXF: flying blind in the Keyframer…
The problem of invisible faces in the Keyframer is because the program
specifies all lines as "hidden" (except for the border) as it creates the DXF
file.
I wrote and uploaded a program a long time ago, (DXFUH.ZIP, I think) that will
preprocess the DXF file and unhide all lines. When you load the processed mesh
into 3DS, all lines (including the diagonals) will be visible. It is painless
and it is free.
JKJ
Thanks, John, I remember this — I took six months off from 3DS (due to
software projects of my own) and kind of stopped my pursuit of making
terrain that way (I also got the Yost routines which do a fractal surface
kind of nice).
I guess I'm trying to come up with some sort of all purpose terrain
generation that suits my animation needs. I'd love it to be as detailed
as I understand VP to be, but if I have to go through all kinds of
conversions to get there I'm not sure just how much it is worth it.
But we'll play around and see — thanks again for the effort of writing
such a program and making it available.
Mike,
>>VistaPro and 3DS…
VP is a lot of fun, and capable of some very realistic detail. Now if we could
just get our 3DS buildings & stuff into VP or the fantastic VP terrain,
textures and colors into 3DS, the combination would be useful as well as fun.
I think VRLI is about ready with a VP -> DXF converter and thinking about how
to output bitmaps effectively for 3DS use. It may get interesting soon…
I took the liberty of sending the DXFUH.ZIP file to you by email in case you
want it – it seems to have been deleted from the forum library.
JKJ
It doesn't seem to be around anymore, though. I looked for dxfuh.zip a few
weeks before siggraph, and couldn't find it. Of course it could also have been
some sort of brain spasm too. If it is still there, and I just missed it, let
me know.
Hey Tim,
Great to meet you at Siggraph. I guess you made it back to the north country
OK? And living in Gus's neck of the woods – wow!
>>po' little lost DXFUH.ZIP…
You seem to be right about DXFUH.ZIP – I couldn't find it in the libs either.
I guess it wasn't deemed useful enough to keep around? <g> Anyway, I took the
liberty to email it to you. I'll send it to Mike Kelly too. Anyone else want
a copy?
JKJ
PS. Too bad about the musical chairs at the event. Up against the dude with
the attitude – you were amoung the gracious and uprooted! Great evening,
regardless.
John,
Hi, a copy of the DXFUH utility is exactly what i need. Could you E-mail a copy
to me. Thanks
I am doing some test for an underwater terrain model and I was going to look
for just such a utility! What a coincidence.
Kurt McKeever 72202, 3562
-Frame of Mind-
Thanks for the upload. It should work until I can get a TIN package here at
work, then I can make landscapes to my hearts content.
Off the subject, but, Hi! It was great to meet and chat with you at the
various Siggraph/3DS affairs. Look forward to connecting with you at future
occasions.
John Tissavary (La Luna cie)
Hello to you, Ditto about meeting you at Siggraph. BTW, what is the (La Luna
cie) mean? I seem to be at a loss, please enlighten. Talk to ya later.
>>…what is the (La Luna cie) mean? I seem to be at a loss, please
enlighten…<<
La Luna means "The Moon" in italian, "cie" is the french abbreviation for
Company, although it is used widely in other western european countries to
denote the same. I chose it as a whatchamacallit for "lunacy/The Moon
Company".
Regards,
John Tissavary (La Luna cie)
John,
FWIW:
To make your business name just a bit more sensible (I know you don't want it
to be completely sensible!), I'd suggest that you capitalize the "c" in cie.
Alec Jason
It's a tough call on the "cie" part of my company name. It is, actually,
supposed to appear in superscript, not capitalized at all. Naturally WINCIM
won't do superscript so you guys get to see a confusing version of the name.
Next time I see you (Siggraph or some such thing) I'll give you a buisness card
and you'll see it's not really that bizarre.
Regards, and thanks for the tip…
John Tissavary (La Luna cie)
Mike (and anyone else who's interested),
A typical "good" Vistapro image consists of 1 to 10 _MILLION_ 3D polygons. I
have rendered images with as many as 150M polygons. The density of the
polygons varies with the camera position. For instance, a tree near the camera
will be be generated with many more polygons than a tree that is far away. So,
in a sense, each scene of a VP3 animation is a seperate 3D world unto itself —
although they're all related of course.
Vistapro is designed to render realistic (or not) looking landscapes, it's not
a general purpose 3D renderer. It has many optimizations and limitations based
upon this goal. 3DS does what it does very well, but it's not designed to do
what Vistapro does.
That said, I'm am currently adding DXF as an output format to Vistapro. I
expect this feature will be used as David Taffet indicates: Use the DXF
landscape as a guide for placing other objects and generating camera paths,
then either throw away the landscape or use it as a matte. Then use a Vistapro
image(s) as a background(s) and use 3DS to render the foreground(s). The one
thing you won't have is accurate shadows cast upon the Vistapro background. I
spoke with Gary Yost a few days ago and he indicated that "shadows on mattes"
was on their wish-list for 3DSr3 but it didn't make it. Oh well, maybe in rev
4!
When saving a landscape as a DXF file you have control over the amount of
detail and the area covered (always rectangular though) by the DXF file. If
the indicated area will turn out to be more than 64K points or faces (the limit
for a single object in 3DS and AutoCAD) Vistapro will automatically save it as
several smaller objects. As the code is currently implemented, you will not
have "smooth" joints between the seperate objects (for those of you who will
want to actually render the landscape) but I _DO_ have a painless solution for
that. Well, painless to you guys anyway! If you want to, you can save several
small areas out in high detail and they will be loaded into their proper
locations (relative to each other) by 3DS.
The DXF objects I create do not contain the 3D trees or 3D fractal detail that
Vistapro generates. Even so, the DXF files are very large: A small Vistapro
landscape at "full" detail (polygon size 1 for those of you who use Vistapro)
makes a 15MB DXF file with 66000 points and 130000 faces. A huge landscape is
1M points, 2M faces, and a 250MB DXF file. If I saved out all the trees and
fractal detail in that 150M polygon rendering that I mentioned above would make
a DXF file of around 60GB! One small consolation though: once you have loaded
the DXF file into 3DS you can save it out as a 3DS object and it will take up
only 1/5 as much space.
Some other things in the works include the ability to save the colors (that
Vistapro would have put on the landscape) as a TGA, PCX or GIF file that you
can use as a texture map in 3DS. These too can grow very large if you want
lots of detail. I also plan to create utilities to translate Vistapro Camera
scripts into 3DS format and vice versa. I may add the ability to load the DXF
objects that I save — but generally not other DXF files.
The executables I sent to a few people for testing was named VP4.EXE but I did
that just be sure they didn't accidentally overwrite their existing VP3.EXE.
VP4 won't ship until sometime next year, but I'm considering a 3.1 upgrade for
those of you who need some of the new features sooner. Enhancements that are
already in it are: optimization for the Pentium, smoother animations at slow
camera speeds and DXF output. Later on I plan to add anti-aliasing, maybe
field rendering, and the ability to have Vistapro spawn a batch file after
rendering and saving each frame of an animation — this will give you the
ability to process the last rendered image, send it to a single frame recorder,
whatever you can do from a batch file.
I'm open to suggestions and input from anyone… Please keep in mind that
Vistapro is MUCH less expensive that 3DS — so don't expect me to do everything
that it does!
John.
As a long-time VP user, I applaud everything you're doing for VP4, John. Keep
up the great work and I'll be looking forward to VP4!
-Alan Iglesias
How can you match the smooth shading between separate objects?
John,
Since my objects represent a single surface it's easy to overlap at the edges
by one or two points/polygons and lower the loose ends a tiny amount so they
disappear under the other objects edge:
1) *aaaaaaa*aaaaaaa* *bbbbbbb*bbbbbbb*
a b
a b
a b
a
b a
b a
b a
* *
2) *aaaaaaa*aaaaaaa*bbbbbbb*bbbbbbb*
b a
b a
b a
b a
b a
b a
b a
* *
Of course these diagrams are drawn with extreme vertical exageration.
Method 1 results in fewer points but I don't know the exactly how 3DS shades at
the edges so method 2 may be necessary. You could do this too, although it's
much more difficult with objects that are already split up.
John.
I don't believe this will work. I know that many rendering algorithms, at a
low level, determine shading based on the enumerations of the points in the
polygons involved. If two points in two polygons are in fact referencing the
same single point in the list of points, then that edge is smooth shaded. It's
faster than computing the normals. In your example, the seams in fact might
have the same normal, but to the algorithm, they look distinct. I'm not sure
how this will apply exactly to 3DS, though…
John,
The idea is that the two seperate surfaces intersect each other. Each one is
itself smoothly shaded. I do not rely on the renderer to smooth between the
seperate objects. Since they are the same shape (except for the very small
bend near the edges which causes the intersection of the two surfaces) they
should be shaded similarly. The question is, how many polygons need to
overlap? Exactly how a loose end is shaded is arbitrarily chosen by the
rendering program. If one or two polygons of overlap is not enough I can go to
three or four — however many is required for the shading algorithm.
John.
I've never written a renderer, so pardon my mistakes, but I thought that with
either Phong or Gouraud shading, a "seam" appears wherever it (the renderer)
thinks that it's come to the topological edge of a set of polygons that are
"smoothed" as a group. I think most renderers check that adjacency by using
the enumeration (index) of points within a point list, because each face stores
only the index of its points, and not the 3D coordinates themselves. It
wouldn't matter if there was overlap, even if the normals were the same,
because the renderer would draw them as separate objects.
In InterChange, there's a "point reduce" tool. It examines an object's point
list. It removes duplicates, i.e., two separate points with distinct indexes
in the point list, yet they have the same XYZ coordinate. It then fixes-up the
point enumerations within faces to match the proper points. Once these
duplicates have been removed, objects that wouldn't smoothly shade in some
programs will now magically smoothly shade, because the "point reduce"
operation repairs all cases where the renderer might want to find adjacency.
On the other hand, some people might use this "seam" effect for artistic
purposes, making the points distinct from each other on purpose. For example,
the "seams" along the parts of a human face.
John,
You must be misunderstanding me at a very fundamental level because you're
arguing my half of the argument!
Consider the following surface (I not going to make the surfaces "rough"
because that's to difficult to show in ascii):
.——-.——-.——-.——-.——-.——-.
. = point
– = face
which gets split into two seperate objects with seperate point and face
(enumeration) lists:
Joint
|
.aaaaaaa.aaaaaaa.aaaaaaa.
.bbbbbbb.bbbbbbb.bbbbbbb.
. = point
a = face on object a
b = face on object b
Drawn with vertical separation for clarity.
There may be an obvious shading discontinuity at the joint. But if you overlap
the edge:
Joint
|
.aaaaaaa.aaaaaaa.aaaaaaa.aaaaaaa.
.bbbbbbb.bbbbbbb.bbbbbbb.bbbbbbb.
Each object is seperately shaded, and since they are the same shape in the
overlaped region, the shadings match at that joint. Now you lower the loose
end of each object to be sure it falls below the other object by a very small
amount — enough so that the renderer renders it behind the other object, but
not so much that it affects shading:
Joint
|
.aaaaaaa.aaaaaaa.aaaaaaa.
.bbbbbbb.bbbbbbb.bbbbbbb.
b a
b a
b a (vertically exagerated
b a for clarity)
b a
b .
.
The intersection consists of two points, one in each objects point list. I
don't expect the renderer to smooth across objects, just that it will calculate
the same shading for each object at the point of intersection, yielding a
seamless joint.
This technique breaks, of course, if you view the object from below — the
flaps will be clearly visible. Another area where there might possible
problems is in inaccurate shadows.
John.
I guess we both agree that a renderer's shading will make the sharp wrinkle at
the edge of a DEM grid look a bit darker than the rest. So you've proposed to
overlap one edge over the other – won't one of them still land on top, and one
will be visible, along with the darkness at its edge?
Enough theoretical talk. Have you tried this in 3D Studio yet? 🙂
John,
I havn't had to try it out yet in 3DS. But note that a decent renderer, with Z
buffering, should properly hide the lowered flaps.
John.
John,
I kludged up a version of VP3 with DXF which overlaps sub-objects at the edges
as I described before. As I expected, there was no discontinuity at the
intersection of the two objects. I'll email the GIF files to you so you can
see the results. One image has two objects that just butt together — you can
see an obvious line where they meet. The other has the objects overlapping and
the line is gone. Now to put the code in "for real"…
John.
Thanks, John, for your very detailed and informative reply — I think
you've well explained exactly why someone like myself WOULD want
VP. My idea is to combine VP in the manner you and David suggested —
by positioning objects with the DXF output you are making possible,
and then using VideoPost in 3DS to combine the images from VP with
3D. The only drawback (substantial, I admit) is that I guess there's
then no way to do flybys or other such stuff — how I'd coordinate the
two programs is beyond me (if I wanted a building or dinosaur, for
example, to be in a landscape with a flyby).
So, I'll probably buy VP anyway, mostly for fun and backgrounds
for 3DS, but now you've confused me about VP4/3. What's the
current version, and what will be the version with DXF output?
When can I buy (approximately) the DXF output version?
.
Mike,
MK> I guess there's then no way to do flybys or other such stuff
Vistapro has the ability to render sequences of images from an ascii based
scripting language similar (but not the same) to 3DS's .VUE files (see pages
B-8 through b-10 in the 3DS manual). I plan to make a utility that will
translate 3DS's .VUE format scripts to Vistapro's
SCR format. This will give you the ability to render from exactly the same
camera positions in each program. Using a Vistapro DXF file as a matte in 3DS
gives you the ability to have objects disappear behind parts of the landscape
(the matte). Anywhere the matte is "visible" (not obscured by a foreground
object) will be transparent — you will see Vistapro's background image.
Anywhere an object disappears behind the matte it will appear as if it's
disappearing behind the background Vistapro image. The disappearance of
objects won't be perfect since Vistapro will render with small details that
aren't in the DXF file, but it should be accurate enough for many situations.
The current shipping version of Vistapro is 3.05. It does NOT have the DXF
export code. 4.0 (which will have the DXF code and much more) won't ship until
sometime next year. In the interim VRLI may make available a version with the
DXF output (and some of the other enhancements I mentioned before) for 3DS
users. There's no release date set yet — it depends, in part, on what new
features 3DS user's require. VRLI will probably charge a small amount for the
DXF release.
John.
Hi John. That VUE utility sounds great. I was driving in my car thinking
about how one could convert a camera path and it's various rolls, pans, FOV
changes, into the sort data that VP could read. I'm not a programmer, so I'm
really glad you thought of it first, because otherwise it probably would have
laid fallow <g>. My thoughts did, to my credit, run along similar lines as
yours, but my lack of familiarity with the building blocks of the two programs
did not allow me to congeal these thoughts into action. I have a lot of
respect for folks like you!
Regards,
John Tissavary (La Luna cie)
John,
As it turns out a .VUE file's "camera" command is perfect for Vistapro. The
arguments are the camera's X,Y,Z coordinates, the target's X,Y,Z coordinates,
the roll (bank) of the camera, and the focal length. The camera and target
coordinates and roll work the same way as in Vistapro. The focal length of the
camera is slightly different — I'll have to figure out the transformation.
Does anyone know the equation that 3DS uses to convert Field of View to Focal
Length and vice versa?
John.
Hi John+John+……,
I have already written a VUE->SCR converter in Pascal, but it was for VP1.0.
(thanks to Phytagoras <g>).
I bought VP3.0 on my trip through CA, but I still havn't it here.
So if the SCR format has not chanced I will upload it with a sample-
file for 3DS. Work's great. I used this converter to create CRATER.FLI
on the "Walkthroughs and Flybyes CD" from Phil Shatz. (Sorry can't upload it,
has 12 MB).
John H. give me a tip if the SCR FileFormat had changed.
John T. are you still in your tent <g> ?
Greetings from Europe
Ingo
Ingo,
Vistapro 3.0 can still use script files from 1.0. 3.0 has a few hundred new
new script commands with which you can control most functions of the program
from a script. Your conversion program should be of use to both 1.0 and 3.0
users. (For those of you wondering about 2.0 — it never existed on the PC;
the numbering of the Amiga and PC versions was consolidated so that 3.0 has
mostly the same functions on both machines.)
It turns out that the "camera" command in VUE files can easily be converted
into Vistapro script commands. The only sticking point is the focal length —
I use a different method and havn't yet worked out the conversion equation.
You didn't work that out did you, Ingo?
I saw "Walkthroughs and Flybys" in a book store the other day and noticed that
it had a few Vistapro animations. Since you mentioned it here, I went out and
bought it. Well, it's tax deductable…
If you can't wait for your VP3 to show up, and want something to play with in
the mean time, download the VP3 demo (<200KB) in DL15 of GraphAVen (GO VRLI).
The demo is mostly functional except that you can't load or save anything.
It's even go a small tutorial built in for those of you who have never used
Vistapro before.
John.
Thanks, John I already loaded VP3demo down before I visit the States.
So I will upload the converter.
>> The only sticking point is the focal length I use a different method
and havn't yet worked out the conversion equation. You didn't work
that out did you, Ingo? <<
No I didn't John. The converter only converts the camera source- and target
points. Perhaps for VP3 I will do it.
>> Since you mentioned it here, I went out and bought it.
Well, it's tax deductable… <<
What do you mean with 'deductable'??, I can't find this word in my
dictionarys.
Geetings from the other side of the atlantic ozean.
Ingo
Ingo,
I'll be looking into the transformation from 3DS focal length to VP3 focal
length shortly. In Vistapro I the focal length is proportional to
1/tan(field_of_view). From a quick inspection of the standard lenses in
3DS, this didn't seem to be the case there.
"Tax deductable" means that the item qualifies as business expense, the
cost is deducted from my gross income so I don't pay taxes on it.
John.
Servus, Ingo.
"Deductible" means "Absezbar" (Steuer weise).
Viele Gruesse von Amerika.
John Tissavary (La Luna cie)
I'm in the tent, but it's falling in on me as we speak <g>! I've finally (!)
figured out the parameters that will give a nice "tent" shape in RESHAPE.PXP.
It's quite a handy tool.
John Tissavary (La Luna cie)
That is great news. The 3DS/VP link is sounding better and better every
message.
John Tissavary (La Luna cie)
>I plan to make a utility that will translate 3DS's .VUE format scripts to
Vistapro's
>SCR format. This will give you the ability to render from exactly the same
camera >positions in each program
Available first quarter '94?
Seriously, I had better buy VP just to encourage you to add these (DXF and
VUE conversions) things to it for us 3Dusers — besides, it sounds like a lot
of fun to play with. Thanks again for the time and information — I hope you
are well compensated for your work.
Mike,
The DXF-output version of Vistapro and VUE->SCR conversion utility could be
available in as little as a week or two.
I originally wrote Vistapro as an entertainment product — to entertain ME! I
think you'll find if fun to play with. I like think of the product as a
computer aided art program, not a rendering package. 3DS users have been
asking for more "compatability" so now I'm working on it. I'm supposed to be
working on something else but I'm taking a few weeks off to do this since it
could result in a lot of exposure in the computer animation industry.
John.
John:
And anyway, you know I won't tell the boss. <grin>
Clint <VRLI>
>The DXF-output version of Vistapro and VUE->SCR conversion utility could
be >available in as little as a week or two.
Available to registered users of version 3.0? I'll go out today and buy it
(well, I'll call around today. Here in Nevada we can't really buy ANY
software
in a store).
Programmers like yourself who have the talent to do 3D stuff really knock
me
out. As a long time (15 years) programmer who has been considered quite
talented in his own field, I feel like a child compared to you guys.
Thanks
for your past and future efforts which end up making life a joy for those
of
us who love this stuff!
Mike,
VP3+DXF will be available to users of any version (except the demo) of
Vistapro. Probably at less than the price of upgrading to VP3 ($45) from
an earlier version. It won't become the regular shipping version of VP3
since it will run very slowly (1/2 speed) if you don't have an FPU.
The DXF version now contains code for saving sub-objects with overlap so
that there is no longer a visible shading disconinuity between them. With
smoothing turned on in 3DS you can't tell where one piece ends and then
next begins.
Now I just gotta figure out the focal length conversion from 3DS to VP3…
John.
It all sounds great. I have two PCs churing out 3DS/VistaPro as samples for a
feature.
I'd like to choose between PAL or NTSC timing in the animations, please.
I'm still going through VP3, although I have done the review. One thing I
noticed was if one lays in, say stars, the horizon is placed over that, and if
the DEM runs out there is an obvious gap between the landscape and the sky. My
main problem is running out of landscape during flythroughs.
Ali
Ali,
AK> I have two PCs churing out 3DS/VistaPro as samples for a feature.
Could you send me a sample of your work on NTSC VHS? I'm always curious to see
what people are doing with Vistapro.
AK> One thing I noticed was if one lays in, say stars, the horizon
AK> is placed over that, and if the DEM runs out there is an
AK> obvious gap between the landscape and the sky.
You can turn off the horizon so that the "ground" outside the topo area doesn't
get drawn. Then stars below the horizon will remain visible. Of course it
will look like your about to fall off the edge of the world when you get near
the edge!
John.
Ali,
I forgot to ask about this the other day…
What do you mean by "choosing between PAL or NTSC timing" in Vistapro?
Vistapro is frame based — it knows nothing about how fast it's output will be
displayed. With the VUE to SCR converter it will generate one Vistapro frame
for each camera position in the VUE file. The VUE file already contains all
the "tween" positions for the key frames.
John.
MakePath Flight Director manual, page 15 "… value is in kilometers per
hour, assuming a playback speed of 30 frames per second", which would make
it NTSC animation speed, not PAL animation speed (25 frames per second),
yes?
You'll notice that 3DS enables the user to choose NTSC or PAL.
ALi
Ali,
AK> MakePath Flight Director manual, page 15 "… value is in
AK> kilometers per hour, assuming a playback speed of 30 fps"
I forgot about that setting in MakePath. In any case, that value is very
approximate.
If you need to make two animations, one at 30 fps for NTSC and one at 25 fps
for PAL, and have them appear to run the same speed on both systems, you can
either increase the speed setting for PAL by 30/25, or decrease the speed
setting for NTSC by 25/30.
For instance, if you generate an NTSC script at 1000, generate a PAL script at
1200 (1000*30/25). Or if you generated a PAL script at 1000, generate an NTSC
script at 833 (1000*25/30).
John.