Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
I forget where exactly I saw it, but it was on this forum somewhere that there is an upper limit to the size of the sprite. I think the specific problem was that the game froze up when a planet sent it's defense fleet, so it could be that the plug-maker was to blame, but I would estimate that, to be safe, you shouldn't make the majority of your ships bigger than 196px, and you can have a few in the 256-352px range, and maybe one or two larger than that that don't ever show up in large numbers.
However, I'd also say it's better to stick with midrange graphics because, as someone who renders graphics, I can tell you that it drastically increases render time to render large. I was working with one image at 512px, and it was taking 4 minutes per frame. I cut it in half (256px) and it took a little over a minute (I'm aware that that is proportionate for the size reduction). I'm working on a ship rendered at 100px and it's taking 30-40 seconds per frame, which is much better and more likely to get me somewhere.
QUOTE (DarthKev @ Jul 30 2010, 01:51 AM) <{POST_SNAPBACK}>
At the risk of turning this into an ongoing dialog, I'm pretty sure we're both missing something here. When I mentioned smallish ships being 200x200, I meant each individual frame, not the entire sheet of frames as I believe you thought I meant.
Also, when you said you never render a spin animation smaller than 300x300, I'm pretty sure you meant the entire sheet of frames is never smaller than 300x300 given your Athena isn't much bigger than an IDA, a 100x100 frame sprite. Again, not what I meant.
No, no. I understood perfectly. Sorry; when I referred to rendering nothing smaller than 300 x 300, I was referring to each individual frame, as my method involves spinning the model within Bryce, producing an actual spinning movie file, and then dividing that into frames using the M2S app. If you go back to my previous post, it should now have one of the original rendered frames for the Athena, and it's pretty darn big.
One thing that I have to fight with in regards to the argument for large sprites is weapon offset. When you make a ship larger, every dimension and every problem is multiplied by the scale. Therefore, a minor one-pixel sprite offset that I didn't notice during initial render can become a big problem when I try to map out weapon ports. I had one small disaster with the original Alexander that somehow allowed it to fire from the proper locations when facing down and up, but was producing shots out of thin air over the ship when facing sideways. It was probably something with the Z-axis, but even still, the problem was multiplied because of the ship's size. I definitely want the biggest sprites possible, because small ones lose so much detail, but there's a balance that must be struck.
QUOTE
Lastly, a curse upon TinyPic for performing maintenance at this time. How dare they prevent us from seeing your beautiful work, even if it is unintentional! That said, how are they able to keep showing your previous images but not the new ones? :huh:
I actually wrote in the little string denoting where the images would be. Apparently when they perform maintenance, no new images may be added, but previous ones will continue to be served. It'll have pretty pictures in it within minutes of me typing this post.
EDIT: The pictures have been added on the previous page in their appropriate post.
This post has been edited by Delphi : 30 July 2010 - 02:47 PM
QUOTE (Meaker VI @ Jul 30 2010, 09:17 AM) <{POST_SNAPBACK}>
1.5 hours sounds way too long for a render. I've rendered some of my ships at 96-ish px completely (all frames, glow, masks) in under 10 minutes. I'll see what it takes for a larger ship (physically larger, not render-larger), since I'm having trouble getting it to load into my scene right now... Part of your issue might actually be the complexity of your texture, and as cool as it looks you might get more mileage using it for just coloring or just bump. I've been running my renders with shaders only, and though I'm working on improving that a little bit I don't feel that they'd look bad run that way.
It's pretty normal for me to have fairly long render times. Keep in mind that this is the render time for the entire 72-frame movie file, not just a single panel. I'm using outdated software running on an outdated computer, rendering models with upwards of 50,000 faces, and applying super-fine antialiasing. The texture isn't really a problem at all. It's actually the sheer model complexity on its own. Even if I were to render the ships in a blank grey material as Bryce imports them, if I set up all my usual options for a final 72-frame render at 300 x 300, the entire procedure would still take at least one hour. The Cyphus battlecruiser has exactly 71,582 faces in SketchUp, which must be triangulated for most other renderers, increasing the total number of polygons to nearly 140,000.
Even the fastest renderers choke on that much data.
Addendum: I would like to note that I've got no problem with these render times. It's only the base sprite that takes so long. The mask, engine glow, and lights all take less than five minutes, usually. I'll often just get the base sprite started and go off to make lunch or whatever. Sometimes that's also when I'll get bored and end up making a new planet graphic. Small details get worked on while the big ones are baking.
This post has been edited by Delphi : 30 July 2010 - 02:50 PM
Speaking of large graphics: I have a question about the Nova sidebar/interface. Does the game have an actual in-engine limit on how large of a graphic it will draw, or will it accept a control panel taller than 768 pixels? I don't like this big black space I've got beneath it right now, and I'd love to fill in some wiring or panels just to make it look complete.
I'll put up the images from the previous page here so that you don't have to jump back and forth between pages to compare my descriptions with the graphics.
Full-size frame taken from Athena spin render
Monolith and Athena escorts over Tirach
1:1 pixel ratio
QUOTE (Delphi @ Jul 30 2010, 11:37 AM) <{POST_SNAPBACK}>
No, no. I understood perfectly. Sorry; when I referred to rendering nothing smaller than 300 x 300, I was referring to each individual frame...
You sir, are awesome.
... as my method involves spinning the model within Bryce, producing an actual spinning movie file, and then dividing that into frames using the M2S app. If you go back to my previous post, it should now have one of the original rendered frames for the Athena, and it's pretty darn big.
Wait, so you render one larger size, and then scale down the frames to whatever size is best? How do you stop it from looking grainy? Whenever I try scaling anything up or down in Graphic Converter, it just doesn't look right. Scaling up is definitely worse, but still. Is Photoshop really just that good at scaling down?
QUOTE (Delphi @ Jul 30 2010, 12:46 PM) <{POST_SNAPBACK}>
I think there might be a limit to how wide the graphic can be, but I don't think there's a limit to how tall it can be. If someone with a shorter screen happens to play your TC, the bottom of the sidebar should just get chopped off with no consequence other than missing out on the extra detail and work you put in.
QUOTE (DarthKev @ Jul 30 2010, 01:57 PM) <{POST_SNAPBACK}>
See for yourself up above. I use photoshop to resize and recolor the entire sprite sheet when I compress it down to the appropriate scale against the other ships. Photoshop has several compression algorithms that it can run, the two most popular being Bicubic and Bicubic Sharper. Bicubic sampling means that it basically runs the entire image through a filter for each level of scaling, sampling neighboring pixels and antialiasing on the fly as it brings the image down to your desired size. So if you turn a 600 x 600 image into 300 x 300, it actually probably does a series of twenty or more interim sizings, cleaning up and resampling at each interval. What you're likely running into with Graphic Converter is standard "Nearest Neighbor" sampling, where it simply checks across and then down to find neighboring pixels and just moves them into place, erasing many others in the process.
The images below were resized from 350 x 300 to 60% of their original size*. The image on the left was resampled using "Nearest Neighbor", and the image on the right was resampled using "Bicubic Sharper".
*Images don't usually look good when scaled by "complex" fractions, e.g. thirds, ninths, tenths, etc. 60% resizing was used to ensure the maximum amount of pixel cleanup possible while still maintaining a good size and not being absurd.
QUOTE (Delphi @ Jul 30 2010, 11:13 AM) <{POST_SNAPBACK}>
Keep in mind that this is the render time for the entire 72-frame movie file, not just a single panel. ... rendering models with upwards of 50,000 faces, and applying super-fine antialiasing. The texture isn't really a problem at all. ... 72-frame render at 300 x 300 , the entire procedure would still take at least one hour. The Cyphus battlecruiser has exactly 71,582 faces in SketchUp, which must be triangulated for most other renderers, increasing the total number of polygons to nearly 140,000.
Well there's your problem. AA and large frames take more time, but as you've said you don't mind so it's not as big of a deal then. I ran one file earlier which was the exact same, other than render image size, and it turned out (duh) that it took longer to do a larger image. Raw face/data count actually doesn't effect rendering that much compared to AA settings, Raytracing, Texturemapping (and other texture sets), lighting, etc. Now, I saw a renderer... I think it was called "octane" which used your GPU and apparently screamed compared to any other renderer, but I don't have a Nvidia chipset and so I can't use it.
QUOTE (Meaker VI @ Jul 30 2010, 02:19 PM) <{POST_SNAPBACK}>
Well there's your problem. AA and large frames take more time, but as you've said you don't mind so it's not as big of a deal then.
I figure that a loss in time is justified by a gain in quality. I hate images with jaggy little extraneous pixels.
There was a time a while ago where I told myself: "Nova uses relatively pixelated small graphics, so theoretically outputting those from Bryce would make it look the best!"
Yikes. I'll stick with large-to-small image compression.
QUOTE (Delphi @ Jul 30 2010, 01:46 PM) <{POST_SNAPBACK}>
The engine will accept an interface bar larger than 768 pixels.
QUOTE (Delphi @ Jun 10 2010, 03:11 PM) <{POST_SNAPBACK}>
Here's a freighter to ply the space-ways, gloriously chunky and ugly as a dog. It probably won't actually end up in the game. It's just my fall-back model in case I can't design a mid-size freighter that I like.
You know, that bears a good resemblance to the Klingon T'ongduj freighters in SFA.
QUOTE (StarSword @ Jul 30 2010, 03:32 PM) <{POST_SNAPBACK}>
You know, you're right, I never noticed that. Except, Delphi's looks scarier with those cannons in front. Klingon ships by principle have generally brutish-looking designs and shapes, but nothing beats a good set of cannons just waiting to blow someone to pieces.
QUOTE (DarthKev @ Jul 30 2010, 06:51 PM) <{POST_SNAPBACK}>
Except for quite possibly MORE CANNONS! Or a ship, that is entirely a cannon!
QUOTE (EKHawkman @ Jul 30 2010, 09:56 PM) <{POST_SNAPBACK}>
Or a ship, that is entirely a cannon!
So like this guy.
QUOTE (EKHawkman @ Jul 31 2010, 12:56 AM) <{POST_SNAPBACK}>
I've seen plenty of ships that are basically a flying cannon. In Halo , the MAC gun (for the uninitiated, basically a railgun) often runs the entire length of UNSC starships. Polaris heavy capital ships in EVN are built around the Capacitor Pulse Laser. And in EVN:UGF, we have the Balcrusian Marauder, armed with a fusion beam whose reaction chamber is just forward of the engines, but whose barrel/focusing mechanism runs from there to the emitter on the bow.
QUOTE (StarSword @ Jul 31 2010, 08:47 AM) <{POST_SNAPBACK}>
A lot of NDC craft are the same. The monolith is built around a pair of Nichron cannons that span the entire length of the vessel, drawing power directly from the aft engine compartment. As a result, its livable space is surprisingly small compared to its size, with the crew protected in a heavily shielded series of compartments in the core of the vessel between the cannon corridors. However, in extreme circumstances the vessel can have its primary coaxial artillery shut down and converted into storage space. The weapon housing is more than roomy enough to make a lot of open air in which to carry nearly anything you could imagine, and the simple aperture fitting at the end of the barrel means the entire section is easily opened for unloading at a spaceport.
How does this relate to the game? Well, do you all remember way back a long time ago when I said there will often be scientific variants of several NDC cruisers? The Monolith, being the standard cruiser of the NDC, has available to it a conversion kit that reduces the number of fixed guns by two but increases the cargo capacity by a monstrous amount, effectively turning it into a hauler, and simulating this theoretical stripping-out of the primary cannons. Once a bit has been activated by purchasing the hauler refit, which simply changes the vessel stats, there is an actual ship-swap upgrade (like the Mod Starbridge) that changes the vessel into its scientific variant, with a different paint job and completely different behavior. It has less guns, a lot of cargo space, and a lot of mass space, though obviously because of the smaller gun capacity you'll be filling this with strategic, scientific systems and the like.
For instance, let's say the normal Monolith ideally carries the usual IFF and density scanning upgrades, as well as two Nichron cannons and perhaps a few Electromag turrets. The scientific version could instead be equipped with only the few turrets (no artillery), but also the IFF/density upgrades, a better multi-jump module, interference-cutting scanners, a faster jump engine, and above-military-grade missile jamming. The regular version supports an offensive player, while the scientific version supports the explorer and defender. Of course, each version is fully customizable, and somebody could probably make a decent science cruiser out of the military variant, and vice versa.
In other news, I'm tackling a little bit of sound design for a while here while I'm bored and between ship renders, so with any luck I'll have a polished sound for the Electromag Laser by the end of today. Yes, I know I already mentioned working on this sound, but I've picked up something of a second wind and convinced myself to sit down and refine it further. I've started playing around with frequency-shifting controls, and it's making it sound really good thus far. They really add that "laser flyby sizzle" that weapon effect in space so desperately need.
Well, I could always go the stark realism way and not include any sound effects in the plug (space carries no sound waves), but that'd just be boring. I'm willing to let fantasy and science blur a little on this regard.
The no-sound in space thing works to an extent, but it needs to be done carefully. Even the updated BSG, which adhered to real-world space physics, fudged this one quite a bit and usually had sounds as would be heard over speakers or from the cockpit of a fighter.
Yeah you're probably not going to hear a random explosion outside of your ship. But if something hits your hull its gonna vibrate and the sound will travel within. Also would be able to hear any weapons you use.
Now I have no idea what it'd sound like, but still.
For my purposes, I actually had the idea for a device that would allow you to hear in space. Though sound doesn't travel through a vacuum via traditional airborne transmission, it is still technically there in a different medium. Because every mass produces a "dent" in gravitational space-time, that means that any changes in the positioning or the structure of the mass will cause ripples. This is why supernovae exert force on stellar objects well beyond the range of their shockwave: the displacement of that much mass causes a giant depth-charge effect on the gravitational plane. By this reasoning, a ship firing its weapons is producing a ripple outward from itself exactly the same as a sound wave. The only difference is that human ears aren't designed to pick up gravitational waves and interpret them as audio, less so in harsh vacuum. It is extremely easy to argue that a soldier who cannot hear is far worse off than the one that can.
To confront this issue, all starships in the NDC universe are equipped with graviton sensors that "listen" for the shockwaves of ships changing/shifting their mass and translate the disruption into an audible sound through speakers in the command center of the spacecraft. When a ship fires its cannons, space is distorted, and the pilot of any neighboring vessel hears the muzzle report. When the ship begins to shift in space and engages its engines, the disruption from both the vessel's general relocation of its mass combined with the energy being released by the engines produces a unique signature that is translated as such.
Ergo, sound in space (more or less).
QUOTE (Delphi @ Jul 31 2010, 11:17 PM) <{POST_SNAPBACK}>
Magic pseudo-science awesomeness
Thank you for existing Delphi(wasn't it originally Sol?). It makes everyday much better. That was a beautiful idea!