 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
I have posted about my jet named the M22 before but I decided that it was time
to post a picture of it. This render is at 1600x1200 with 0.3 antialiasing and
it took roughly 3.5 days to render.
CREDITS
-thanks to Kevin Loney, Jaap Frank and Tor Olav Kristensen for there isosurface
to mesh conversion include file
-thanks to Rune Skovbo Johansen for his particle system which was used to make
the smoke trail
-thanks to the POV community for all the help whether directly or indirectly
-thanks to the POV-Ray developers for developing such a great piece of software
A little background:
I started modeling this jet 100% in POV-Ray SDL back in March 2008. I've worked
on it very slowly since then. The chassis version you see here is an
isosurface, but I also have mesh and CSG versions. I started this whole thing
because I eventually wanted to make a dogfight sequence but that's a long way
away.
By the way I am aware of the following problems with this render.
-there are 2 artifacts at the engine-nozzle area
-where the cockpit glass meets the main chassis of the plane the blue colour is
suppose to be dark grey
-there is a small shading artifact on the nose cone of the closer plane
All comments and criticisms are welcome.
Bridgeofstraws
Post a reply to this message
Attachments:
Download 'm22 sample scene 3.jpg' (340 KB)
Preview of image 'm22 sample scene 3.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bridgeofstraws" <bri### [at] inbox com> wrote:
> Hi,
>
> I have posted about my jet named the M22 before but I decided that it was time
> to post a picture of it. This render is at 1600x1200 with 0.3 antialiasing and
> it took roughly 3.5 days to render.
>
> CREDITS
> -thanks to Kevin Loney, Jaap Frank and Tor Olav Kristensen for there isosurface
> to mesh conversion include file
> -thanks to Rune Skovbo Johansen for his particle system which was used to make
> the smoke trail
> -thanks to the POV community for all the help whether directly or indirectly
> -thanks to the POV-Ray developers for developing such a great piece of software
>
> A little background:
> I started modeling this jet 100% in POV-Ray SDL back in March 2008. I've worked
> on it very slowly since then. The chassis version you see here is an
> isosurface, but I also have mesh and CSG versions. I started this whole thing
> because I eventually wanted to make a dogfight sequence but that's a long way
> away.
>
> By the way I am aware of the following problems with this render.
> -there are 2 artifacts at the engine-nozzle area
> -where the cockpit glass meets the main chassis of the plane the blue colour is
> suppose to be dark grey
> -there is a small shading artifact on the nose cone of the closer plane
>
> All comments and criticisms are welcome.
>
> Bridgeofstraws
Very nice! I, too, am working on some aircraft, both for animations and for the
POV-ray Object Collection. I am not using csg/isosurfaces, but mostly meshes
produced in Wings3D, as I find that easy to work with. Of course, when dealing
with meshes, you have to worry about mesh resolution and files sizes and such,
but they render much more quickly. *shrug* there is always a trade off.
I've gotten the body shape done on mine, but at some point I need to do the
landing gear, as well as the interior and pilot. However, instead of
continuing on that model, I find myself working on a new, VTOL model...
Out of curiosity, are you going to add control surfaces? Also, how will you
place your craft? I was going to use the spline_trans macro, but it doesn't
provide enough info directly, so I think I am going to have to partially
re-write it.
-Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Reactor" <rea### [at] hotmailcom> wrote:
>
> Very nice! I, too, am working on some aircraft, both for animations and for the
> POV-ray Object Collection. I am not using csg/isosurfaces, but mostly meshes
> produced in Wings3D, as I find that easy to work with. Of course, when dealing
> with meshes, you have to worry about mesh resolution and files sizes and such,
> but they render much more quickly. *shrug* there is always a trade off.
>
> I've gotten the body shape done on mine, but at some point I need to do the
> landing gear, as well as the interior and pilot. However, instead of
> continuing on that model, I find myself working on a new, VTOL model...
>
> Out of curiosity, are you going to add control surfaces? Also, how will you
> place your craft? I was going to use the spline_trans macro, but it doesn't
> provide enough info directly, so I think I am going to have to partially
> re-write it.
>
>
> -Reactor
It's good to know someone else takes interest in jets as much as I do. :) To
answer your questions, I do intend to add control surfaces, landing gear,
weapons, a fully automatable cockpit, and a pilot. This project will take
quite a while but I imagine it will be worth it. I've already developed a way
to do the flight path animation. I used 2 spline to do this. One spline is
used to adjust the jet's roll while the second spline is for actually moving
the jet. I used the Reorient_Trans with the direction my jet normally faces
(before moving it or rotating it) and a rough approximation of the derivative
of the spline at the current point in time. The reason I used this instead of
the spline_trans is because I had to move the smoke trail in a way not possible
with the spline_trans macro. The spline_macro should work great if you are just
moving the jet. Even if you wanted a lot of control on the banking you could
use the spline_trans with no banking and use a separate spline to roll, similar
to what I did.
I can understand why you're making the aircraft as meshes. If I was much better
at mesh modeling I would too. They`d certainly make longer animations more
possible because they are so fast to render. Something that may interest you
is that half the rendering time was spent on the smoke trail because of the
high max trace level I had to use to remove artifacts and the amount of media
the smoke uses.
Bridgeofstraws
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bridgeofstraws" <bri### [at] inboxcom> wrote:
> It's good to know someone else takes interest in jets as much as I do. :) To
> answer your questions, I do intend to add control surfaces, landing gear,
> weapons, a fully automatable cockpit, and a pilot. This project will take
> quite a while but I imagine it will be worth it. I've already developed a way
> to do the flight path animation. I used 2 spline to do this. One spline is
> used to adjust the jet's roll while the second spline is for actually moving
> the jet. I used the Reorient_Trans with the direction my jet normally faces
> (before moving it or rotating it) and a rough approximation of the derivative
> of the spline at the current point in time. The reason I used this instead of
> the spline_trans is because I had to move the smoke trail in a way not possible
> with the spline_trans macro. The spline_macro should work great if you are just
> moving the jet. Even if you wanted a lot of control on the banking you could
> use the spline_trans with no banking and use a separate spline to roll, similar
> to what I did.
>
> I can understand why you're making the aircraft as meshes. If I was much better
> at mesh modeling I would too. They`d certainly make longer animations more
> possible because they are so fast to render. Something that may interest you
> is that half the rendering time was spent on the smoke trail because of the
> high max trace level I had to use to remove artifacts and the amount of media
> the smoke uses.
>
> Bridgeofstraws
That sounds pretty similar to what I've been looking at in terms of movement. I
wanted to take it a step further by making the control surface orient themselves
and making vapor trails appear at the right times (by computing curvature &
speed, then placing media containers if the path curvature falls within a
certain range).
I've already cut up and parametrized the control surfaces so that they can be
animated by supplying a value in the range [-1,1], but I haven't done the
landing gear yet, which will be slightly more complex, but not significantly
so. One issue that I have encountered is the loose tie between frames and real
world time. I want things like the aircraft navigation lights to flash at a
specific real-world interval, but some scenes may require additional frames for
motion blur averaging.
What are you doing for the engines? I started by using an emission media, but I
wasn't satisfied with the appearance. I am considering using a partially
transparent textured cone (or more than one).
Also, if you are still considering a mesh-based approach, I may be able to help
if you are using Wings.
-Reactor
P.S. Attached is an untextured view of the model in progress. The mesh file is
about 1.4 MB, stats on a P4 3.0GHz (single core):
Peak memory used: 35522439 bytes
Total Scene Processing Times
Parse Time: 0 hours 0 minutes 0 seconds (0 seconds)
Photon Time: 0 hours 0 minutes 0 seconds (0 seconds)
Render Time: 0 hours 5 minutes 32 seconds (332 seconds)
Total Time: 0 hours 5 minutes 32 seconds (332 seconds)
CPU time used: kernel 10.88 seconds, user 313.52 seconds, total 324.39 seconds
Render averaged 1109.77 PPS over 360000 pixels
Post a reply to this message
Attachments:
Download 'ac10 test_2.jpg' (23 KB)
Preview of image 'ac10 test_2.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
High!
Nice contrails - but usually, they start only at a certain distance from
the jet nozzle, as the exhaust gases need to cool to crystallize!
See you in Khyberspace!
Yadgar
Now playing: I Should Care (Taco)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Reactor" <rea### [at] hotmailcom> wrote:
>
> That sounds pretty similar to what I've been looking at in terms of movement. I
> wanted to take it a step further by making the control surface orient themselves
> and making vapor trails appear at the right times (by computing curvature &
> speed, then placing media containers if the path curvature falls within a
> certain range).
> I've already cut up and parametrized the control surfaces so that they can be
> animated by supplying a value in the range [-1,1], but I haven't done the
> landing gear yet, which will be slightly more complex, but not significantly
> so. One issue that I have encountered is the loose tie between frames and real
> world time. I want things like the aircraft navigation lights to flash at a
> specific real-world interval, but some scenes may require additional frames for
> motion blur averaging.
>
> What are you doing for the engines? I started by using an emission media, but I
> wasn't satisfied with the appearance. I am considering using a partially
> transparent textured cone (or more than one).
> Also, if you are still considering a mesh-based approach, I may be able to help
> if you are using Wings.
>
> -Reactor
>
> P.S. Attached is an untextured view of the model in progress. The mesh file is
> about 1.4 MB, stats on a P4 3.0GHz (single core):
> Peak memory used: 35522439 bytes
> Total Scene Processing Times
> Parse Time: 0 hours 0 minutes 0 seconds (0 seconds)
> Photon Time: 0 hours 0 minutes 0 seconds (0 seconds)
> Render Time: 0 hours 5 minutes 32 seconds (332 seconds)
> Total Time: 0 hours 5 minutes 32 seconds (332 seconds)
> CPU time used: kernel 10.88 seconds, user 313.52 seconds, total 324.39 seconds
> Render averaged 1109.77 PPS over 360000 pixels
It looks like you are much further in to your project than I am. I haven't even
thought about control surface alignment or variable contrails. I would love to
know the equations for determining this stuff. I may not have sufficient math
background to understand it instantly but that would make animation of the
plane look so much more realistic.
I had thought about using lights on the aircraft before and what I planned on
doing when I got there was just use a constant frame number to real time ratio.
And if I wanted to add motion blur to parts of the video I was just going to
use VirtualDub (http://virtualdub.sourceforge.net/ - I have an older version)
which has a filter that does motion blur for you with no extra time spent
rendering more frames. However, I'm sure that rendering more frames and
averaging them would probably create a better result. I just don't want to add
extra time rendering my animation if unnecessary.
The engine effect for my jet was done using a fairly turbulent bozo patterned
emissive media with a cone shaped container. Right now it isn't the best, but
it is a start. If you like I may be able to render some closer up views of the
flame.
I appreciate the offer for help with Wings but I don't think I'll pursue mesh
modelling for this plane. However, I could use some help figuring out how to
lower poly counts on the mesh generated from my isosurface with Wings or
Blender (if you use it). Basically my mesh is generated from the isosurface by
sampling every n (specifiable) units in a 3D grid like fashion. This mesh
generation approach requires that you generate a very fine sampling in order to
get some of the details in the isosurface but afterward I'm stuck with a 2
million vertices mesh that looks terribly blocky. I've tried to use blender to
reduce the vertices count but I can never seem to get the mesh rudders smooth.
Hope this makes sense. :)
I really like your aircraft. I can't believe how smooth the mesh for it is.
Did you use radiosity to light the scene? Anyways, that is an awesome
aircraft.
Yadgar - I never knew contrails formed like that. Thanks for the tip!
Bridgeofstraws
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bridgeofstraws" <bri### [at] inboxcom> wrote:
> It looks like you are much further in to your project than I am. I haven't even
> thought about control surface alignment or variable contrails. I would love to
> know the equations for determining this stuff. I may not have sufficient math
> background to understand it instantly but that would make animation of the
> plane look so much more realistic.
>
I am not planning on making it completely accurate so much as visually correct.
I simply rotated the various control surfaces into what I felt looked like a
reasonable minimum and maximum position, and made the macros from there. The
macros I currently have are fairly simple - the one below rotates the control
surface in place about a local axis within the object.
// rotates pAngle degrees about an arbitrary
// axis as defined by points p1 and p2:
#macro trans_rot(p1, p2, pAngle)
#local p3 = (p2 - p1);
transform{
translate -p1
Axis_Rotate_Trans(p3, pAngle)
translate p1
}
#end
This one is used to get the angle that will be supplied to trans_rot - the
position is user supplied from [-1,1], but the minimum and maximum angle is
defined for each object.
#macro ac_int_getAngle( fposition, minAngle, maxAngle )
#local fposition = min( 1, fposition);
#local fposition = max(-1, fposition);
#if( fposition >= 0 )
#local fangle = fposition * maxAngle;
#else
#local fangle = -fposition * minAngle;
#end
fangle
#end
The two above macros are called internally for positioning, the only thing the
user has to call are the "external" parts, which look like below:
union
{
ac10_main_body()
ac10_right_leadingSlat( 1 )
ac10_left_leadingSlat ( 1 )
ac10_right_flap( 1 )
ac10_left_flap ( 1 )
ac10_right_aileron( 1 )
ac10_left_aileron ( 1 )
ac10_right_horizStabilizer( 0, 0.75 )
ac10_left_horizStabilizer ( 0, 0.75 )
ac10_right_rudder( 1 )
ac10_left_rudder ( 1 )
translate <0,5,0>
}
These macros place the all of the parts in their fully deployed position except
for the horizontal stabilizer's trim setting, which is neutral, and the
elevator, which is at 75% max. I felt parametrizing was the best way to go so
I wouldn't have to remember the angles each part needed to be at.
I haven't done it yet, but I think I could use most of the existing spline_trans
macro, and move the control surfaces automagically based on the aircraft's
movement... the problem, of course, is that a high performance aircraft will
keep the orientation it is at when the controls are neutral. That is, the
control surface position cannot be based on orientation only, since it would
not make sense for an aircraft that has rolled onto their side and maintained
sideways flight to still have the flaps in a position that would make the
aircraft continue to roll.
What that means, as far as I can tell, is that the position should be partially
based on the derivative of the orientation "curve," so to speak. For instance,
when the aircraft is rolling hard, the flaps should be at their most extreme
position when the orientation rate of change is the highest and at the neutral
position when the orientation is no longer changing, regardless of what it is.
Unfortunately, my vector calculus isn't very good, otherwise, I would have
finished this already with an part that calculates instantaneous curvature,
which would allow one to place vapor trails (at pre-defined locations).
Of course, this is the hard way to do things. The other way is to simply make
more splines that define the control surface positions at various parts of the
location/orientation spline, but... *sigh* there would just be something very
nice about having an aircraft model that positions its control surfaces
correctly in responds to its path and instantaneous velocity... you could even
make the exhaust flames longer when it moves at higher speed, or make it deploy
the flaps in level flight when it is at very low speed, or... wait, I should
finish the model first.
-Reactor
(First part of a multi-parter!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bridgeofstraws" <bri### [at] inboxcom> wrote:
> I had thought about using lights on the aircraft before and what I planned on
> doing when I got there was just use a constant frame number to real time ratio.
> And if I wanted to add motion blur to parts of the video I was just going to
> use VirtualDub (http://virtualdub.sourceforge.net/ - I have an older version)
> which has a filter that does motion blur for you with no extra time spent
> rendering more frames. However, I'm sure that rendering more frames and
> averaging them would probably create a better result. I just don't want to add
> extra time rendering my animation if unnecessary.
>
Understood. The only reason why I was slightly concerned about that (and the
control surface positioning thing) is because I am making this with the intent
to put it into the Object Collection, and I think it would be much easier to
use if the user could just tell it where to fly and whether or not the lights
should be on, off, or flashing, and it took care of the rest.
> The engine effect for my jet was done using a fairly turbulent bozo patterned
> emissive media with a cone shaped container. Right now it isn't the best, but
> it is a start. If you like I may be able to render some closer up views of the
> flame.
>
> I appreciate the offer for help with Wings but I don't think I'll pursue mesh
> modelling for this plane. However, I could use some help figuring out how to
> lower poly counts on the mesh generated from my isosurface with Wings or
> Blender (if you use it). Basically my mesh is generated from the isosurface by
> sampling every n (specifiable) units in a 3D grid like fashion. This mesh
> generation approach requires that you generate a very fine sampling in order to
> get some of the details in the isosurface but afterward I'm stuck with a 2
> million vertices mesh that looks terribly blocky. I've tried to use blender to
> reduce the vertices count but I can never seem to get the mesh rudders smooth.
> Hope this makes sense. :)
>
> I really like your aircraft. I can't believe how smooth the mesh for it is.
> Did you use radiosity to light the scene? Anyways, that is an awesome
> aircraft.
>
> Yadgar - I never knew contrails formed like that. Thanks for the tip!
>
> Bridgeofstraws
Thank you, and yes, I did use radiosity (when it is untextured and the plane is
white, it is hard to see exactly what is going on). The mesh is fairly smooth,
but there are a few bits that could use more smoothing. I usually keep the mesh
low density for ease of working, then do a smooth-on-export with recursion level
1. This means that the working one is about 2000 vertices, whereas a smoothed
export one is closer to 8000. I plan on making 3 or so resolutions - 2000 is
more than enough for a high-speed moving spec, whereas a ground scene may
require a fully smoothed model, which is closer to ~32000.
Of course, after that, one needs a burning model, a crashing one, an exploding
one, one crashed on the ground, one partially disassembled for maintenance...
Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I must admit I like your idea to parametrize all the control surfaces with
macros (that expect a value from -1 to 1) because even if you do control the
surfaces with splines, at least it will be easy to specify their angles
realistically.
"Reactor" <rea### [at] hotmailcom> wrote:
>
> Unfortunately, my vector calculus isn't very good, otherwise, I would have
> finished this already with an part that calculates instantaneous curvature,
> which would allow one to place vapor trails (at pre-defined locations).
>
> Of course, this is the hard way to do things. The other way is to simply make
> more splines that define the control surface positions at various parts of the
> location/orientation spline, but... *sigh* there would just be something very
> nice about having an aircraft model that positions its control surfaces
> correctly in responds to its path and instantaneous velocity... you could even
> make the exhaust flames longer when it moves at higher speed...
I agree that it is very desirable to make the plane practically fly itself. I
was hoping to get this to work, but I hadn't brought control surface animation
into the equation before. I have exhaust flame length changeable currently and
plan to add the control surfaces you talked about. My main concern in relation
to this is how I might figure out at what speed the airplane is traveling
because this would effect the degree to which, for example, the ailerons would
tilt during a roll to rotate so many degrees per second.
>or make it deploy the flaps in level flight when it is at very low speed, or...
Now that would be amazing! In some ways it could also suck because you might
want to do a surrealistic maneuver but then have your code do something
unexpected.
> wait, I should finish the model first.
I also find myself forgetting this... :)
>Thank you, and yes, I did use radiosity (when it is untextured and the plane is
>white, it is hard to see exactly what is going on). The mesh is fairly smooth,
>but there are a few bits that could use more smoothing. I usually keep the mesh
>low density for ease of working, then do a smooth-on-export with recursion level
>1. This means that the working one is about 2000 vertices, whereas a smoothed
>export one is closer to 8000. I plan on making 3 or so resolutions - 2000 is
>more than enough for a high-speed moving spec, whereas a ground scene may
>require a fully smoothed model, which is closer to ~32000.
>Of course, after that, one needs a burning model, a crashing one, an exploding
>one, one crashed on the ground, one partially disassembled for maintenance...
Thanks for letting me know about the "smooth-on-export" feature of Wings. That
alone may warrant me learning Wings modeling because I can think of quit a few
cases in which this would be useful (none relate to the jet unfortunately -
unless maybe the weapons).
Well, I wish you a happy holiday!
Bridgeofstraws
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
