landeTLS

Which of the terminologies are you unsure about? An Operand means the object you use to boolean into your main object. English isnt my primary language so my explanations can get a bit exessive. Sorry about that.

The quick and dirty way is to bake out an ambient occlusion map and multiply that ontop of your color layer. But just doing that wont give you the result you see on for example the mk3 cockpit there. That result is made with a more hand painted approach. i would think it was made by segementing/paneling in ps/gimp then manually "bleeding" the colors. I think i saw some tutorials by cpcipard somewhere here on that process.

Add another horizontal loop in the center before you apply boolean. Reduce the boolean operands segements to 8. Connect the 4 corner verts to the closest edge making it all quads. like this just without the inner inset loop (not nessecary for lowpoly, also ignore the subdivision going on there). Most important thing to avoid artifacts here is to not try to cut a too segemented(dense) piece into a piece without enough segements to define the curvature. Basically you would need more segements on the big cylinder to hold its curvature if you boolean in a high density operand. Hope this makes sense. the picture above is the best case scenario. But you can get away with more operand segements if you terminate the polygons well(not so many in one place, and avoid terminating on the vertical between two curving polygons) and/or increase the big cylinder segements enough so that you have the operand going through 3/4 segements instead of just 2. The horizontal loops can be terminated into tris just after passing into a planar segement.

public bool engineIgnited for if its active. maxThrust / finalThrust for "percentage" of output. EngineIgnited might be outdated. May need to test it. Maybe isOperational is now used like others have said. hope this helps.

What necrobones said. In addition you are limited to 256 tris (if i remember correct, might be verts) for each collision mesh. But this is still probably more than you need. Its probably better to combine several colliders to match more complex shapes (since these dont contribute to extra drawcalls). I prefer the primitive box collider in unity for adding protruding collider pieces. But there may be some performance issues by using exessive amounts of colliders. Its also not currently possible to make concave (shapes with holes in them) colliders work in ksp. In order to make them you need to arrange several colliders to make up your shape

no problem, i just thought of another fun performance test to run. hipoly vs lowpoly w/ big maps take one cylindrical hipoly model with 20-40k triangles(lots of greebles on it), bake out a big normalmap from it and perhaps ao to a plain cylinder. create mu files with same collider for both. but put a 1x1 texturemap to the hipoly model(this is to keep the game from temporarily freezing as it is looking for a nonexisting texture map), and the 1024x1024 normals/diffuse to the plain cylinder. put a bunch of each on two different vessels and check avarage fps over 60 sec. i might run it later. just saw the trick with the fps in fraps now, thanks to necrobones for pointing it out

actually youll be happy to know, i did another test after a modeling session. this time on my main gaming/rendering pc and the results are much more conclusive. there is actually about a 16% gain in performance in using an oversized atlas over single maps(in this case, might be even higher in most cases) 2015-06-20 03:07:00 - KSP Frames: 1505 - Time: 60000ms - Avg: 25.083 - Min: 9 - Max: 29 //this is with single 1024x1024 texture maps 2015-06-20 03:10:11 - KSP Frames: 1747 - Time: 60000ms - Avg: 29.117 - Min: 7 - Max: 35 //this is with the single 4096x4096 atlas map epic stack of tanks is epic. sorry no FPS overlay, forgot that fraps doesnt work that way

Yea. Take my theorizing with a grain of salt. It may be that the performance does indeed not take any hit what so ever by using big atlases across many parts over single per part maps. A quick google search did not uncover any good resources on this in a performance context. I kindof wanna test out using a 4096 atlas across a bunch of parts vs 512 single ones to see if there are any difference in fps. In any case its good practice to prioritize decreasing drawcalls on your meshes. Ie avoiding multiple materials/texture maps on single parts as well as attaching objects into one as much as possible. Texture size and this does much more for your performance than does polycount edit: i did a quick atlas vs single maps experiment with my potato laptop(intel i5-460m @ 2.53ghz, ati radeon 5650 1gb, 4gb ddr3 ram) graphics card is a bit on the weak side, so this one barely runs ksp with full texture resolution(at 10-20fps..) these are the results: as you can see the results where quite even, if you can see the tiny fps view in the upper right corner. the avarage was about the same for both the 4 parts with the single 1024 maps vs the 4 parts sharing a 4096 atlas map. i didnt do any more detailed checking because most differences will probably mostly be on account of noise on this laptop. the single maps did seem to perhaps have a higher peak fps but the avarage was 8-11 for both atlas and single. i set this up by picking a part that didnt use a normalmap and used a big texture(i picked one of the kerbodyne tanks that uses a 1024x1024map) i then duplicated the folder 4 times and renamed the parts in the cfgs. i then duplicated all 4 folders and scaled one of the texture maps to 4096x4096, put it in a seperate folder and scaled down the texture maps of those 4 parts to 1x1 i then referenced the texture atlas in the cfg of those 4 parts, and renamed them. you can download the gamedata folder here if you wanna try it out. it would be easier to distinguish any differing results if the test is run on a more suitable (low>midrange with a slightly petter gpu) computer, and if running a better fps logger. Its probably easier to see any differences if more of each parts are used edit: sorry to the op about cluttering his thread with discussions of tiny optimizations. hopefully his questions got answered.

Using a big texture across many parts/models (i believe its called "texture atlasing" or something thereabouts) is a good idea for memory savings, and with limited memory available with the 32bit based ksp this becomes good practice in almost all cases. But to delve more into detail each drawcall must now reference a big texture file rather than a smaller one, it could perhaps lower the performance compared to multiple moderatly sized maps. (For example you have 4 parts. Eather using 1 x 2048map or 4 x 512maps) But this is where my knowledge of the processes really falls short. Ksp keeps all assets loaded at all times. Ram/ddr memory is very fast and gpu memory is even faster so the fact that multiple operations may be referencing the same memory blocks at the same time should not be a performance issue. But the bigger map size may be an issue as for example each mesh rendering operation on our 4 parts must now reference the 2048map (4 x 2048) vs (4 x 512). But again there may be some batching/caching or other smart programming going on in the background to make this less of an issue(inside directx/opengl and/or in unity). So unless someone here has some more in depth knowledge, testing it ingame may be the best way to know for sure.

Unity splits up single objects that are over 65k polygons to multiple drawcalls/objects automatically. I was able to get a model with over 1m polygons into ksp. But since it was split into almost 20 drawcalls the performance was a bit low. In eather way his engine is only about 6k polygons not 60k so he is way below the treshold where unity needs to start splitting objects. Might be that unity counts verts here and not polygons. I dont remember. But in that case you are even better off as youll usually have less verts than polygons (triangles)

Regarding A: yes to a small degree but texture size is still much more important. Think of it as what will tax the gpu/cpu most: The gpu is designed to render many points quickly through threading, this makes it excellent for rendering many polygons. But textures are one big 2d image that need to be painstakingly projected onto those polygons. I dont know so much about the internal processes here but from experimenting iwe seen that even lower end machines (that can barely run ksp smoothish by default) can easily handle moderately higher poly objects with small textures, its when you put in 1024++ textures on the parts that you get one figure framerates. E: 64bit wont do much/anything for performance. The major advantage as i see it is the ability run more mods in your game. I tell you, i was trying to get ksp running just with the full nearfuture pack and some kopernicus planets + agressive texture compression. and there is just no way of balancing it to not go above the memory limit after a few launches. There may be a mem leak somewhere but even without that im too close for comfort to the memory crash limit after load.(for me the game crashes at around 3.4gb-3-8gb) Btw: did they optimize the mainsail? I thought i saw it at higher polycounts earlier.

Yes that was what i was getting at. It gets a bit cumbersome to explain properly because different softwares use different terminology. Basically You can have as many detached parts as you want, but they should be part of the same object (atleast when exported to unity)otherwise youll incur extra uneccesary drawcalls. To further clarify you do not need to boolean or attach the meshes physically together, just attach them so they appear as 1 object in the inspector view. There are cases where youll want them to be seperate objects. Like if you are animating them through basic parent/child based rigging(one example is the standard engine gimbal setup for the nozzle). If you use different texture maps for them and/or you need a different shader for the objects.

Polycount doesnt do much in the way of memory or performance for that matter. Texture size is much more important. As a second concideration many unmerged/unattached objects in your part will slow down performance. When it comes to polycount i usually dont care so much about the count but instead i just try to keep the polygons even'ish in size. Ie as cylinders taper in their segements decrease or a smaller cylinder gets less segements than a big one. I would compare a rocketengine in ksp to a weapon in an fps game for reference on how many will appear in a scene. Given that you can use too many polies but the tipping point is probably somewhere around 20-60k (depending on scale) for few use parts. And that is being quite conservative(given that ksp is played on low end computers, but in those cases you are still much more limited by texture size). Yours is now about 6k. Just emagine how wastefull you would need to be to reach those kinds of numbers. For many use parts like fueltanks etc. You should probably be aiming for less than 5k polies. also. When i say polies/poly im talking about triangles and not quads, so for a nontriangulated model youll be looking at the triangle count and not the polycount. An example in ksp is the mainsail. It is around 10k polies if i remember correctly. hope this helps Update: improved explanation a bit and formatting

Like this? Nameofyouranimationstate.normalizedTime = 0; "=".normalizedSpeed = 0; This will stop the animation and set it to the start time. If the light is off at this time in the animation then you should be good. You can also use blend to get a smoother transition. Or you can reverse the animation with normalizedSpeed = -1; and clamp it when it reaches 0. Hopefully i didnt misunderstand what youre trying to do here. If so then just ignore this:-P

How about: bool isMach; Public Void Update () { float mach = (float)vessel.mach; If (mach >= 1f && !isMach) { //post your message isMach = true } if (mach < 1f) { IsMach = false } } this should only show once each time when the craft breaks mach 1

Youll need to manually remove the meshrenderer component from your collider inside unity

Noob(me) to the rescue change if (mach == 1) to if (mach > 1)

Inside 3dsmax you can set the units scales in customize->units setup. Set it to meters for working with ksp. Also set system units to meters. I believe the default is inches etc.(1 inch = 2.54 centimeters) you can also det it to cm but then youll need to import to unity at 0.01 scale. Another helpful thing is to set the grid spacing to 0.625m so that each grid space from the center represents each ksp size (1.25,2.5,3.75 etc.) You do this by rightclicking on the snaps toggle and choosing homegrid. When importing fbx files(with meters as unit scale) into unity its important to set its scale to 1 (instead of the default 0.01 etc.) If you dont want to fiddle with that and dont have any animation rigs you want to get into unity then just export in obj. its a bit confusing but it comes from the fact that unity works only with meters and everything else is therefore assumed to be in meters on import. Btw: every damn time!

yup thats it. In your newest pic it looks much better. Regarding "shininess", in unity you set a material with a specular shader like ksp/specular (? Not sure if this is its name i havent been inside unity for a while). You dont need anything else for it to look shiny but using an alpha to control which parts look shiny/shinier makes it look a bit better. You can test this out approximately how this will look in your modeling software by applying specularity to your material (assuming wings3d supports that, i should think so)

Looks nice. No visible texture distortions. Except perhaps the frame is getting a bit too little texture resolution. The textures look a bit muddy there. But there is no picture of the new uv layout tho(unless those thin lines around the details on the texture map are the uv layout?). So im unable to give pointers on it. On the texture pic there looks to be a big spot where there are no uv islands at all.

I guess transform could be a dummy transform you created like so Transform DummyTransform = new Gameobject () as transform; dont have access to a computer now so not sure if thats correct. Otherwise you could do: Gameobject dummy = new Gameobject (); Transform dummyTransform = dummy.transform; Its position (transform.position) is probably used to place the attachnode when invoked this way. So its probably a good idea to set its position first But im a noob with c#. Im also doing some wierd stuff with attachnodes and really wish there was some good resources on how to work with them in code

O i must have remembered wrong. I thought OnUpdate () ran regardless of staging but OnFixedUpdate () ran only after staging. Sorry for the confusion. Then as lo-fi said it is better to use Update () which runs regardless of staging since this is unitys own frame callback. That is unless you want to integrate some functionality with ksps staging timeline.

Some ppl also use mudbox for texture painting directly on your 3dmodel(projection painting). I havent really tried it but its similar to the same feature available in blender and zbrush(projection master). The advantage as i see it over flat texturing in ps/gimp is that you see the result as you paint. This is very useful for painting extra scratches etc. Tho some things like adding geometric shapes edge effects and patterns are much better done i ps/gimp imo. Ofcource if you are just texturing other ppls models then ps/gimp might be the only thing you need. As said texture baking(color/ao/normals/cavity from highpoly or directly from your lowpoly) is also very valuable in the texturing process but not required

Public void onUpdate() should be public void Update ()(if using monobehaviour callbacks) or public override void OnUpdate () if using ksp callbacks from PartModule?* *questionmark because im a total noob at c#

myself i would probaby use normals to make those indents on the side but assuming you wanna keep them you have an issue in the uv seams setup where the "frame" around them is connecting at the start and the end, you can see this in the uvmap(lower left).make a single seam down the vertical line and it should unwrap more evenly. see http://www.polycount.com/forum/showthread.php?t=94010 you can still keep the frame uv island seperate from the indents if you want them to overlap etc. also its hard to see in the pics but did you camfer all those tiny corners of the indents?, if so then that is completly unnecessary. another potential issue is that the intersection of the frames are not made of quads, not that all quads are required for lowpoly but you could get mesh/texture artifacts if the ngons in those areas gets triangulated unfavorably inside unity. Most 3d modeling software auto unwrappers also appears to favor intersections made of quads. The straight sections in between can use ngons. But if they curve then youll get shading artifacts. hope this helps i was going to open your model in 3dsmax and take a look at it but max does not support the wings3d format. Update: improved my explanation a little bit. Sorry i dont speak english as my primary language