Decals in OpenRocket: a not-so-quick and fairly complete tutorial

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Thanks for that, I've been meaning to try out the nose cone. It looks like it is treated like a tube, but with the front shrunk down, so the decal image is distorted. It would be an interesting challenge to do something useful with it.

I will admit that decaling the launch lug didn't occur to me. :wink:
 
Now let's play. We'll go back to the rear fins and set the "Repeat" option to "Sticker". This means that exactly one copy of the decal image will be placed on the target, like a, um, sticker. We start here:
dd_test_rear_single.png

Now let's try the X scaling option. By default the scaling values are 1, let's set X to 0.5 instead:
dd_test_rear_stickerx.png
This is pretty straightforward. The decal has been scaled by 0.5 in the X direction. It is pinned to the front/left of the object. Because it is a sticker, there's one copy of the decal and everywhere else shows the background.

Now we can see what the other Repeat options do. Here's "Repeat":
dd_test_rear_repeatx.png
The decal image repeats as many times as necessary to cover the target; in this case exactly two copies are needed because we set the scale to 1/2. This option generally made no difference when the scale values were set to 1, because the single instance of the decal already completely covered the target.

"Repeat and Mirror" does the same thing, but flips alternate copies:
dd_test_rear_double_mirrorx.png
This can be good for making repeating background patterns, if you don't want to do it in the paint program.

Finally, "Clamp Edge Pixels":
dd_test_rear_clampx.png
This is interesting. It shows a single instance, like "Sticker", but now the background is all red. What this option does is fill the background with the edge pixels of the decal image. This is why it is typically the best choice when using a single decal image that completely covers the target: it ensures that the edges are completely covered, and you don't get a bit of background color showing at the edges. So I've modified the first post in this thread to suggest that when using the simplified method described there, always use "Clamp Edge Pixels".

Now let's go back to "Sticker", and try scaling Y instead of X:
dd_test_rear_stickery.png
Pretty easy to understand now, although perhaps a bit surprising that the single image is pinned to the bottom rather than the top. Oh well!

So what happens when we do the same thing to the body tube wrap? Using the "Repeat" option, let's set X scale to 0.2, so we should see 5 copies of the decal in the X direction:
dd_test_bt_repeatx.png
That is a bit surprising. For the body tube, the X axis is around the circumference of the tube, rather than left to right. Oh well #2!

So if we scale Y instead, it'll do this:
dd_test_bt_stickery.png

And here it is with the "Repeat" setting:
dd_test_bt_repeaty.png
Yeah, there's some weirdness here, but once you know what it's doing it's easy enough to deal with.

I didn't show any examples on the middle fins, because they behave exactly like you'd expect. Try it out yourself if you like.
 
Last edited:
Thanks for taking the time to show us how this works. I've been trying to figure out how the controls work, and I wasn't getting very far.

I've been meaning to try out the nose cone. It looks like it is treated like a tube, but with the front shrunk down, so the decal image is distorted. It would be an interesting challenge to do something useful with it.

I will admit that decaling the launch lug didn't occur to me. 😉


I was looking at the various missiles that were done by Jesús Manuel Recuenco Andrés in the Open Rocket Design website, and noticed that some of them had details on the nosecone. That's how I learned that it could be done (but not exactly how to use it). The LL trick was something I noticed would be needed if the Estes Wizard's wrap completely wrapped around the body tube and LL.

My first attempt with a nosecone decal was with the Estes Scion.

Now I know how to *fix* my sims. Look for those to appear in my .ork file thread soon.
 
Last edited:
Thanks for taking the time to show us how this works. I've been trying to figure out how the controls work, and I wasn't getting very far.

Hope I'm presenting it in a useful fashion.

I think I have two (or maybe three) more posts to go before wrapping up.
 
Let's say we want to apply our original square image as a "sticker" on the forward (parallelogram) fins. The first thing we'll do is set the scale so it's square. Since those fins have a 2:1 aspect ratio, we'll cut the X scale to half of the Y scale to return it to square:
dd_test_front_sticker1.png
However, the sticker remains pinned to the lower left corner of the bounding box. So let's see what the X and Y offsets do. Set both of them to -0.5 and get this:
dd_test_front_sticker2.png
The first thing to notice is that the negative offsets moved the sticker in a useful direction, to the right (X) and away from the BT (Y). Positive offsets would have moved the sticker in the opposite directions, which are generally not that useful, so *usually* you'll use the negative values. You'll also note that a negative value of X offset moves the decal in the *opposite* direction of a negative offset of a component when building the rocket. Oh well!

Anyway, the value of an offset represents a distance equal to a fraction of the size of the component along that access. So, for X, -0.5 puts the left edge of the decal exactly halfway back on the fin. Likewise, for Y, -0.5 puts the bottom edge of the decal exactly halfway up on the fin.

If we wanted to center the sticker on the fin, we'd have to figure out the right values, either by trial and error or by measurement and calculation. Here's the final result:
dd_test_front_sticker3.png

On to body tubes. Let's set the X scale to 0.5, so the sticker extends exactly halfway around the BT, and Y scale to 0.2, so it's small and manageable (it's *not* a square at this point, though; more precise calculation would be needed to achieve that). Initially it looks like this:

dd_test_bt_sticker1.png
Now let's set X offset to 0.25 and see what happens:
dd_test_bt_sticker2.png
+0.25 has rotated the decal exactly one quarter of the way around the BT, "upwards". So we can guess what -0.25 would do:
dd_test_bt_sticker3.png
This is one instance (the only one?) where positive and negative offsets are potentially equally useful.

Y offsets behave as you would expect; here it is with Y offset = -0.5 (yes, we're back to negatives now):
dd_test_bt_sticker4.png
The decal is moved exactly halfway back on the BT, just like on the fins (although on the fins that was the X axis).

We've now covered everything necessary to do about 99.9% of all decal work you'd want to do. To me, the simple approach described at the beginning of this thread, and the guiding principle of not touching the controls, still looks a lot more inviting than fiddling with the offset and scale controls. But if you ever find yourself needing to adjust something in OR and you just don't want to muck around in the image editor, you know what to do.

Last post in this series will cover rotation.
 
Last edited:
Really, what I want most from it right now is for it to be stable on the Mac. It's a crazy crash-fest right now.

I've noticed that on my Mac with El Capitan 10.11.3 I can not apply decals at all. It will either render the model as totally black with a black background or either crash. On my old Mac running 10.9.5 I can add decals just fine. Both have the latest version of Java (8 update 73). Very frustrating!
 
I've noticed that on my Mac with El Capitan 10.11.3 I can not apply decals at all. It will either render the model as totally black with a black background or either crash. On my old Mac running 10.9.5 I can add decals just fine. Both have the latest version of Java (8 update 73). Very frustrating!

I'm on Yosemite still and thankfully haven't had that particular problem... in fact I think I've isolated it (mostly) to one thing: switching from one of the 3D views to a non-3D view (side or back). That is a 100% repeatable crasher for me. So I've worked around it for now by simply never using the 3D views. Instead, I keep a photo studio window open on the side. It's not awesome to work that way but it beats the crashing.
 
I've got to say... I've been having some fun with what I've learned from this thread.







Mind you, I'm not done yet, I've got to go teach a lesson so it'll be several hours before I'm ready to upload the new updated file. (Read: I'm all hot and bothered... Why should I be alone?)
 
Last edited:
Ok, new trick for aligning decals on the body tube in OR.



You might not realize it, but the decals for the Cherokee D were carefully aligned using my MK1 eyeballs. Mind you, the eyeballs haven't been calibrated in some time, and may be out of calibration. However, for the Cherokee D, it's fine.

The decals for the Velociraptor are a different subject.



That fin can decal would likely show it's out of alignment pretty easy, and eyeballing it isn't. So, how to do this and make it look GOOD?

After creating the long diamond shape and applying it to the body tube paint and decal test image I crudely drew Roman numerals ahead of them, and after applying that to the .ork file, I could see how they needed to be adjusted in relationship from each other. If "3" was too close to "1" I could edit the image to move it away from "1". That was all fine and dandy, but verifying the centerline between the fins was a problem. The solution? Fins.

I made a trio of fins that were rotated to be centered between the actual fins. These alignment fins are .001" thick, .25" high, and the full length of the fin can. With those to guide me, I could easily tell if any of the decals were not centered properly.

After I was happy with their locations, I deleted the alignment fins, and the Roman numerals, then saved the file. Sure, I can't zoom in on it and tell 100% if they are exactly centered, but they're a lot closer than they were just using the eyeball method.

HTH
Jim

Oh, and about the Velociraptor. The "VELOCIRAPTOR" decal splits between the O" and the "C" on the actual prototype seen at Tammie's Hobbies in Beaverton, and not between the "C" and the "I" like I have here. The actual widths of the prototype's black and silver bands have yet to be determined, but as there's no painting guide with specific dimensions, it's up to the individual builder to choose how wide they want them.
 
Last edited:
I've noticed that on my Mac with El Capitan 10.11.3 I can not apply decals at all. It will either render the model as totally black with a black background or either crash. On my old Mac running 10.9.5 I can add decals just fine. Both have the latest version of Java (8 update 73). Very frustrating!
See this thread about OR crashing on the Mac:

https://www.rocketryforum.com/showthread.php?133080-Help!-OpenRocket-keeps-quitting-unexpectedly

Great set of instructions in this thread and thanks to everyone else who chipped in.


Tony
 
Something I just discovered about fin decals... So you have a fin decal, and it refuses to "sit right", you play with the adjustments for hours, days, weeks... and you still can't get it to ever look right. Something to ask yourself...

Do I have fin tabs? :facepalm:

SURPRISE!!! Those stupid tabs are your problem... Adjust your decal's "height" by the height of the fin tab. Voila! It finally works...

Any guesses on how I discovered this? :facepalm:

In the images below, you can see the difference that factoring in the fin tab can do... The image on the left and fins on the left reflect the correct exposed dimensions of the decal, whereas the right side fins and right side image are what happens when you don't factor the tab in. If you want you can download the .ork file and test it yourself.





While the graphic files for both sets of fins have the same height for the yellow and red bands, the black band was altered to reflect the fin tab.

View attachment Fin Frustration.ork
 
Last edited:
...Really, what I want most from it right now is for it to be stable on the Mac. It's a crazy crash-fest right now.

Hey Neil, I think I might have two possible solutions to your issue.

First up, VirtualBox (Link). Note: I have quite a bit of "End User" experience with VBox, on Micro$oft hosts. (Dollar sign is an Ode to Redmond's greed)
Basically, you install VBox on your computer (aka "The Host") and use it to run virtual sessions (aka "The Guest") of other OS's. For the Host computer, VBox can run on OS X, Linux, Solaris and M$ Windows.

There are two big caveats in using VBox;
1) You will need an ISO image of the Guest OS.
2) the Host computer must have enough system resources to support both the Host and Guest operating systems. This means multi-core CPU's, a lot of RAM and copious amounts of hard drive space. eg. Installing Win7 requires a minimum of 4 Gigs RAM and 25Gigs HDD/SSD storage, but can run a tad sluggishly with that config.

The other option is Wine (No, not the kind you drink). Wine, now known as WineHQ (Link), creates a compatibility layer and translates Windows API calls into native OS calls in real time. Note: I have only used Wine on Ubuntu and LinuxMint boxes, so I know almost nothing about it's machinations within OS X.

If you are interested in trying VBox, just let me know. I can start a new "How-To" thread of installation and use.
 
Thanks, but no longer an issue since I learned how to get rid of the 3D view crasher. I have used virtual box but am not a big fan for various reasons.


Sent from my iPad using Rocketry Forum
 
A follow-up tip on transparency

Normally, I would prefer to apply the base color to the component normally, and then apply a decal image only where the actual decal would be, using transparency as necessary. However, I've found that fades to not look as good when implemented with a transparent decal image.

Look at the following image. In the top sample, the decal is full coverage: a blue fade and white background, covering the entire component. Looks good.

1600270742623.png
In the bottom sample, The decal is just the blue part, fading to transparent, and showing the white body tube underneath. Note how the light part of the fade looks greyish rather than pure blue. I've also found that sometimes (can't seem to reproduce it right now though) the transparent decals will show "edges" where there aren't any, and look bad.

Therefore, I've taken to having my decals be solid color covering the entire component whenever there are fades and such. Looks better in general. Solid stuff with sharp edges like test or roll patterns can work either way.
 
Last edited:
Hi everyone,

I am making a brief post here just as a method of indexing this apparently tremendously useful thread, which I intend to study in detail.

Stanley
 
Nose Cones and Transitions

Nose Cones and Transitions behave just like body tubes, except... not quite. You're still starting with a rectangular image, but the image is warped to fit the surface. Consider the following decal image:
checkers.png

Here it is, applied to three components: a nose cone, a body tube, and a transition. All have the same length as circumference, so on the body tube the squares stay square:
1615043012398.png

Just by looking, you can see how the image is being warped to shape the surface on the nose cone and transition. This has implications:
  1. The decal image appears in OR differently than if you printed it and applied it to the rocket
  2. Trying to get a particular image to appear undistorted requires that you reverse-distort your image
Item 2 is very hard to describe properly, so I'll just illustrate with a couple of examples.

Here's a transition on Biohazard as rendered in OR. The pinstripes have constant width:
1615043942466.png
To achieve that, I created this decal image:
transition_wrap.png
The ratio of line thickness at top and bottom of the image is equal to the ratio of the top and bottom diameter of the transition. This one was pretty easy.

Nose cones with their compound curves are harder, and I rarely try to get them perfect. Here's the rendered nose cone from Plasma Dart II:
1615044929407.png
Here's the decal image:
pdii_nose_decal.png
Note that in the image, the tapered stripes have straight edges, but when mapped to the curved nose in OR they came out... well, curved. Trying to get them straight on the rendered nose was simply not worth the trouble. As it turned out, I liked the look of the curves, so I made the decals slightly curved. Here's a pic of the finished nose, which ended up pretty close to the OR render:
1615044893792.png
So that's all I can think of to say about noses and transitions. They are a pain in the neck, no doubt about it. Familiarity with more sophisticated paint and/or drawing apps is definitely a plus.
 
Here's something for those of you who are interested in metallic finishes... Only works (as is) for round components (nosecones, body tubes) and not things like fins. After applying them, you may need to rotate them (x axis) to get the desired look.

Chrome:
1615527267696.png
Copper:
1615527072184.png

Gold/Brass:
1615527211587.png

Here's a sample of what's possible now...

1615527527164.png
 
Last edited:
My understanding is that there is no way to have the two sides of a fin with different colors/decals. I that correct?

Yes, it's rather silly feature to want...
 
My understanding is that there is no way to have the two sides of a fin with different colors/decals. I that correct?

Yes, it's rather silly feature to want...
Yes (and no), and Not yet...

Can you make a fin with different colors/decals on opposite sides? No... But you can fake it. I do it all the time. The next version of OR (or one of the more recent developer's versions of it) can handle it.

Here's an example of a rocket with fins that have different decals on the sides: The venerable Astron Cherokee-D (K-47)


To do it, each fin is actually multiple fins (in this case, I'd be using 3). If a fin has a decal on one side but not on the other, yet they have a common appearance otherwise, I will use two fins. The common appearance fin is the one that gets the regular position, lets say 0, 90, 180, and 270 degrees. The fins that have the decal are offset by a few tenths or hundredths of a degree to allow the decal to show though on the desired side, but not on the other. Those fins are then made from "air" (which is given a zero mass), and attached to a "Phantom Body Tube" (PBT). To get accurate flight info, deleting the PBT will give the correct CP/CG for the sim.
 
Can you make a fin with different colors/decals on opposite sides? No... But you can fake it.
Yep, I've read about adding phantom fins. I don't think I want it bad enough to do that. ;)
The next version of OR (or one of the more recent developer's versions of it) can handle it.
I may play with that. Does a clone of github "unstable" generally run OK? I'll need to figure out how to generate a .jar from the source tree — it's been a long time since I did any Java development (and I never did very much).
Here's an example of a rocket with fins that have different decals on the sides: The venerable Astron Cherokee-D (K-47)
Very cool. I always wanted a an Estes Cherokee D when I was a kid, but it was a bit beyond my budget. I've got a Semroc Cherokee D kit waiting to be built. I'm really a sucker for the retro kits that are repros of the ones I wanted but didn't have 50 years ago.
 
I may play with that. Does a clone of github "unstable" generally run OK? I'll need to figure out how to generate a .jar from the source tree — it's been a long time since I did any Java development (and I never did very much).f
Yes, the unstable branch currently runs pretty well, and there are only a handful of issues to resolve before we can move to a public beta (those handful are non-trivial and will still take a little while).

I managed to get the unstable branch building on my Mac using Ant, despite not being a Java guy *at all*. If you PM me I can show you what I'm doing right now.
 
It looks like building a .jar using ant is pretty simple, but I'm getting a variety of compiler errors — missing packages, invalid constructors, mismatched argument lists etc. I suspect that openjdk 1.8.0 is too old for openrocket unstable. Java 8 is required by an RC plane/heli simulator I use. I believe it should be possible to install Java 11 alongside Java 8, but I don't have time to figure that out at the moment.
 
Yes, Java11 is the recommended version.
Good to know, thanks. Word is that the next version of the plane/heli simulator (heli-x.info) will work with Java 11. Hopefully that will be out soon. Then I won't need to figure out how to have two versions of Java installed.
 
But wait, there's more...

I have 3 more bits of decal tomfoolery to describe. First up:
My understanding is that there is no way to have the two sides of a fin with different colors/decals. I that correct?

Yes, it's rather silly feature to want...
Silly or not, it is now possible. And so...

...Using a Different Decal on Each Side of Fin

Version 22.02 of OpenRocket adds the ability to have a completely different appearance on each side of a fin. It's *slightly* tricky so let's go through it.

Let's start with a simple demo rocket with a 2-fin set. This makes it easy to see the appearance on each side of the fin. We'll use this simple decal file:
left_fin.png
It looks like this:
right-backwards.png
As expected, one side of the fin has the text backwards. We will need two different decal images to make this work.

In the appearance panel for fins, you now check the box that says "Use separate appearance for left and right side(s)". When you do, you get a new little tab bar that has separate options for "left" and "right". The appearance we've already defined is assigned to "left", and now "right" starts at the default:
both-sides-fins.png
And so after checking this box things look like this:

both-sides-fins-result.png

Note that "left" means the left side of the fin, looking from the rear, assuming the fin is vertical at 0 degrees. A better designation would probably be the "counter-clockwise" side, looking from the back, because that correctly covers fins of any orientation. Anyway.

Let's see what happens if we apply our existing decal to the "right" side:
left-decal-on-right-fin.png

You can see that the text looks better, but the whole thing is flipped. Well it turns out that for the right side decal, the orientation of the fin shape within the decal image is flipped horizontally. And so let's try this decal image for the right side:
right_fin.png

Here's the result:
both-sides-correct.png

By golly I believe that's exactly what we wanted. No more annoying doubled fins! (ORK file is attached)

Finally, note that the entire appearance of each fin side can be different. Different color, shine, etc. You can even have different opacity on each side, which is every bit as weird as you might imagine (and not very useful).

That's it for this one. More to come!
 

Attachments

  • fin-decals-both-sides.ork
    11.2 KB · Views: 0
Back
Top