PopaR

added a render of the station and one of the ships to my deviant: http://nanoether.deviantart.com/

An import plugin should be able to convert all of a models assets or references to assets to something that AM understands. Likewise, an exporter should convert the AM references or assets into something that is understood by another program. The ideal should be the ability to convert a file to a mdl, then take that mdl anb convert it back and have the original program not see a difference. However, taking the development of a plugin in steps allows the chance to test the parts and allow others to test the parts. It also allows others to build upon a started but dropped project, or improve a part, without starting from scratch. Some exporters may need helper plugins to ensure that the assets of the mdl are correctly placed, or meet the standards of the target format. At some point, it may become possible to integrate the seperate helpers into the export process, at least as final checks, to make sure that it will perform as intended. Sorry, didn't mean for the tone, didn't notice until I reread it a few days later. And I hadn't noticed that Rodney had given some sample milestones.

I think this is the last major concern for planet building: the habitability zone (AKA, the goldilocks zone). A good article, with a graph based on solar mass can be found here: http://science.howstuffworks.com/other-earth1.htm Generally, unless I was going to feature an eclipse, as long as the sun looks far away it is probably OK in most instances. In those instances where your distance does not give you the correct, or the desired results, some trickery can be used, like negative lights, changing out the type of light, etc.

Mars and Earth are about 56,000,000km apart at thier closest. In scale that would be 190,000cm, or 1900m. (fudged the numbers to get rid of trailing 6s) For Earth & Venus, the distance is about 24,000,000km. In scale, that is 80,000cm, or 800m. In both cases, the closest passing distances were used, but they are often further away.

Guess I may as well put my two down. A nif import/export Which will require at least one helper plug in and recently, A new bake texture. I get why the generated texture is flipped, and I think I know why most of the patch maps are rotated, but I will have to dig through the code to find a real solution.

Yeah, I'll probably want to do that. Anyways... Just sat down and decided to figure out what the optimal planet size & scale were being targeted by the modifier. This is not hard, since it is designed to give you an Earth-like planet. The secret lies in Polar Distance. It is set for 22cm, so assuming the axial tilt is around 30 degrees, 1/4 the cicumference is 33cm, full circumference is 132, using the formula to find the circumference we get a radius of about 21cm. Now for scale, Earth has a radius of about 6371km, so the scale factor is roughly 300km to 1cm, or 30,000,000 to 1. A reasonable scale for dealing with planetary systems. For reference, one AU (average distance between Earth & Sun) is about 150,000,000,000km, so 1AU would be 500,000cm or 5000m at that scale

So, how does one go about intelligently creating a planetary surface with the Planet modifier? The way I'm going to do it from now on is this: first, set Polar Distance to equal the radius, and set Ice and Snow to 5. all of these will get tweaked later. The actual basic land mass generation is governed by Feature Size and Seed. Looking a bit deeper into Feature Size, it is the rough size of a land mass when water is set to 50. which is why you get lots of little islands when you have a low value on a large model. so, if you have a model that is 10m (1000cm) in radius and you want 4 or 5 main land masses, you need to start with Feature Sizes around 1570 (2×1000×3.1417=6283.4, 6283.4÷4=1570.8). Note that when two features are generated too close to each other, they combine together. The Seed alters how the generator creates the features,its relationship to the terrain being generated probably requires a deep understanding of fractals and their generation. Seed does have a range limited from 0 to 16384 inclusive. So, get your rough Feature Size to where you want it, then play with the seeds until you find an arraingement of landmasses you like. don't worry too much about mountains and such, we'll adjust them shortly. Next we play with Frequency, Amplitude, and Octaves. I gave the impression that I don't understand these things, but I do, at least when it comes to RF waves. Freqency is the distance between peeks or between troughs, or a complete cycle of the wave. Amplitude is how high above & how low under 0 the wave goes. Octaves are used in music and each octave is twice the value of the octave before it and half of the octave after it. So, the more octaves you have, the more variability in frequency you should get. So, according to the current thoughts on planet formation and aging, a young or geologically active planet should have tall jagged mountains, so high values should be used. An old or geologically inactive planet should have soft weathered mountains that aren't very high, so use low values. You can use Bump Strength to further tweak how strong or weak the terrain is. Offset will shift the average height generated up or down, with 50 being centered. This has a few uses, but its effects are similar to altering the water level. Any changes beyond this need to be done on baked texture maps. Now for final tweaks: Polar Distance, Water, Ice, Snow, Depth Noise, and Water Depth. I start with the water, the value shifts the water level up and down, and there are a number of other calculations going on that adjust moisture related features, such as snowcaps and vegetation. Sins I am working ob water, I adjust its appearance. Depth Noise and Water Depth add the appearance of shallow and deep water. A little science here: light from the sun strikes the ocean, part of this light is reflected off, but some of it penetrates and reflects off of things that are underwater, such as the seabed, some of this light gets trapped while some of it makes its way back to the surface and is effectively emitted. But, the light can only penetrate so far before it looses all of its energy, there are two zones that receive light, the sunlight zone (surface to 200m), and the twilight zone (200m to 1000m), light does not penetrate any further. So, any water deeper then 200m is not going to reflect much light back, and anything deeper then 1km is not going to reflect any. It can be argued that if the ocean was pure water, with nothing in suspension or solution, that light could penetrate further, which is why we can adjust these settings. Water Depth sets where light has nothing to reflect from (on earth, this would be a little past the 200m mark). Depth Noise is how clearly the seabed is reflected out (the composition of the water causes light to scatter, which is why the depth adds noise). On to the other side of water. I like to start with the Polar Distance, and I start with the planets axial tilt, this is in relationship to the planets orbital plane (assuming a simple system with one, maybe two suns). The main cause is the axial tilt, but even a planet with no tilt will have icecaps (if it has enough moisture), distance from a source of external heat (light) can do this (you can think of Europa as being one giant icecap). Since planets with a tilt also have seasonal shifts, we are looking for the average, which is easy: it is the Axial Tilt. Getting to what we need is a bit more work: ((90-Axial Tilt)÷90)×((Radius×PI)÷2). What we are doing is finding out how far the edge of the icecap is from the equator, as a percent (we could convert to rads, or use trig, but why), next we need to know how far it is from equator to pole, since its 1/4 the circumference (2×PI×r), we need the circumference divided by 4, finally, multiplying them together gives us the distance. If your planet is closer to its sun, you should increase the distance, and decrease it if its further. Ice and snow I adjust to suit my taste. If you are going to show seasonal progression, create a north and south hemisphere and set each to have the material, and make all of the values match. This will be your spring and fall/autumn settings, When a hemisphere is in winter, the Polar Distance should be decreased slightly, and the Ice & Snow adjusted to suit deep winter snowfall & freeze, for summer the opposite should be done. And the hemispheres should be set as opposites (summer in north its winter in south; winter in north its summer in south). The only two settings I have not covered are Mottle Size and Mottle Magnitude. These determine the size and strength of vegetation coverage. I generally leave them as is & do any changes on the baked maps.

Forgot, there are settings in the material shortcut that can be edited to rotate the material. So, here is what happened with a model that is 4 patches high and 8 around The map file is eight units across, like before, but the first patch is not the top. heck, the entire first column is flipped vertically in relation to the model. And I was wrong, there may be four strips that were generated running around the model, but the seperation has been moved into the equatrial patches. So, the function assumes a n-s orientation, and it is best to work with that, even with the flipped & rotated sections.

Bad news, the material did not rotate. But that is alright, this is about how the bake works. And it does not help anything. It does verify that each patch gets its own map in the file though. Well, now that I know more, off to tweak my model.

Playing with the Planet material combiner, here is some info: (Looks like I will have to isolate some of these to see what they really do) Feature Size is how large the features are. This is not keyed to how large the model or patches are, so a "physically" large model will need larger values to get actual land masses and not a whole mess of tiny islands. The number of patches has no bearing on the calculations, in fact my station renders the same surface with 64 patches as it did with hundreds. Polar Distance is what the ice caps cover. It is the distance from the equator in cm, a value of 0 turns this off. It appears to be along the surface, not the y-axis. It really should have been an angular measure, as the icecap would depend on how the planet rotates in relation to its orbit; a percentage would heve worked too. As a reference, if you set your PD = to the planets radius you get about a 31 degree coverage. Water primarily affects the elevation of the water. Not sure whether it is a percentage of the amplitude, but it is easiest to treat it as such. The best range seems to fall between 20 and 80; below 20 is barren and over 80 is waterworld. This does affect vegetation and snowcap generation. Bump Strength is surface roughness, as a percent, as is standard in AM Ice is a percentage of coverage to the equator. It has 2 big effects, adding ice to snowcaps and ice to icecaps. A value of 0 turns it off. Frequency Factor is similar to roughness, it appears to be the underlying surface that is modified by roughness, amplitude, and octaves. Amplitude Factor is a percentage. Appears to act like roughness or frequency factor. Octaves alters the waves generated by Frequency and Amplitude Noise Factor adds chaos to some of the other generators, it is most noticable in Polar Distance and Ice. Seed is used to generate the terrain and allows the terrain to be generated in the same way with a certain selection of settings. Offset is a percent, looks like it shifts the median up and down, affecting terrain generation. Mottle Size affects how fine or coarse the generated color map is Higher numbers mean larger clumps means coarser, lower is opposite Mottle Magnitude ?? it is a percentage Depth Noise another percentage, uses the terrain that is underwater to affect the shading of the water. Max Depth caps the values for water depth? Snow the last percentage. Affects snow coverage, works in conjunction with Polar Distance and Ice to provide coverage The material does not generate a displacement map, and in most cases I would agree that it would be overkill, and I may just go with bump maps after I block my shots. Wish it had a seasonal adjustment, thought that was what snow was going to do, but no. A seasonal would shift the north and south hemispheres in opposition, with the middle being spring/fall, one end would have summer in the north and winter in the south, the oppositer end would swap the seasons. This can be done manually, actually, if you seperate your north and south hemispheres and apply a copy of the materials to each, you can shift your snow/ice coverage and move your icecap towards the equator. Now to bake it.

Changing bump did not create a bump map, so I have moved on to the other option, figuring out the exported maps. This is what I have found out about maps created by the Bake Surface function. The surface being baked is a partial sphere with the Planet material applied. The model was created with the N-S poles aligned to the Y-axis. The surface is 4 patches high, forming 4 rings; each ring has 16 patches for a total of 64 patches. The maps created is an array of maps in an 8×8 pattern. For reference, the top row is 1 and the bottom is 8. Each row is numbered from left to right from 1 to 8. The maps in rows 1, 3, 5, and 7 are in one hemisphere and those in 2, 4, 6, and 8 are in the other. The maps in 1-1, 3-1, 5-1, and 7-1 are in the -x, -z quad, with a spline along the x-axis (z=0). The next set (2) are counter-clockwise when looking from above, and proceeds around the model. When set 8 is reached, it continues in rows 2, 4, 6, and 8. The maps in 1-1, 3-1, 5-1, and 7-1 are flipped horizontally while the remainder of the maps have been flipped horizontally and rotated 90 degrees clockwise. The function exports the following maps: ambiance intensity, bump, color, reflectivity, specular intensity, specular size, and transparency. Next I will try this on a "planet" that has its poles aligned to the z-axis, as the x-z plane is the plane AM flattens models in, and see what happens.

Still working on assets Trying to get the "that's not a moon" space station done. Figured out why trying to bake the texture was crashing AM, too many patches, and it was baking all of the materials. So even though I hid the cloud layer and other parts, it was still baking those surfaces. Created a new model & copied part of the model over to test, got a good bake, but it didn't bake displacement, and the image files are not edit friendly. So, next step is to remodel the surface. I really don't need the density anymore. I was using the splines to check placement of surface details I had added. Just some simple lathing, but I have to make sure everything lines up. I think I will try to ramp up the "bump" value and see if that gives me a decent bump map.

The normals issue can be vexxing one, I've set my default to not show backfacing patchs. But I still have to manually go through the model to check it, and sometimes they seem to flip for no reason. In fact, one of my mouse buttons is set for F(flip normals)/Shift+P(select patch). There is a refind normals function when you right click in the modeling window, but it goes away when you select a patch. It seems to me that you could use a selected patch to find the correct front face. Back to the emitter idea. some issues to address: Placing the emitter - if it is a temporary object created by the plugin, it has to be persistant until activated to allow for correct placement (switching through at least two views, and being moved repeatedly), and possible multiple uses. Keying the emitter(s) - the emitter may need to be keyed to an object, otherwise nested or complex objects may be affected. Take a head as the example, often the eyes and interior of the mouth are seperate objects with some normals that face into the head. These patches may be exposed to the emitter, flipping some of the normals incorrectly. Holes - holes in the model could expose exterior parts of the same model to the emitter, flipping them incorrectly (you hid the mouth and eyes, but now the emitter hits the eyebrows and nose) I'm not saying it is not something to think about, just that there are potential problem areas that need to be worked out

So that the "Starting to write hxts" (https://www.hash.com/forums/index.php?showtopic=47624) topic isn't flooded by what is wanted, I created this topic. Feel free to post things that you'd like to see developed here.

Found this: by Jeff Paries http://www.digitalproducer.com/pages/explosions_in__animationmaster_.htm It's AM98, so a few things have changed. He has links to an mpeg & the project file. This tutorial is for a space based explosion