Shadowmage

Not really -- KSP 'slows down' physics to make sure it is processed with the same number of 'steps' per simulated in-game second. It is actually Unity's/KSPs 50hz physics simulation (and lack of low-level PhysX access) that result in the current maxima for friction outputs. If I could crank it up to 500hz (with integration of access PhysX sub-stepping), or 1000hz (ideal minimum for spring/damper simulation), the simulation could be much more accurate. Basically due to limitations in Unity, the simulation is 1/20th as accurate as it could be. References: https://forum.unity.com/threads/wheelcollider-substeps.466617/ https://forum.unity.com/threads/whats-a-good-way-to-integrate-custom-substeps.326926/ If you look at this graph -- I need hooks into the 'Internal Physics Update' block, with the ability to manipulate the forces applied the rigidbody, and apply specific force inputs immediately. https://docs.unity3d.com/Manual/ExecutionOrder.html Sadly, Unity does not support that. There are options for integration that do not rely on substeps (e.g RK4), but I would still need discrete access to the RigidBody along with 'immediate physics updates' for the forces I apply, as well as some way to 'rewind' those forces (as I need to check rigidbody position for four force inputs to calculate the four derivatives to use for calculating the actual spring value and damper values).

I think the difference in grip between two different tread types, on a typical tracked vehicle, would be minimal. Also, at the physics simulation level, the friction is already set to 'max' for all wheels/tracks -- there really is no more friction that can be added without 'adding energy' to the system (although, the current simulation would work better/be more accurate/appear to have higher friction if the code were run at a higher update frequency -- the discrete time-steps limit the friction output so as to not cause jitter issues).

Increasing the mass will make it sink more. Or... you can supply a custom drag-cube for the bouyancy calculations to use, but not sure how that might interact with any existing drag-cubes on the part (might need to provide both a 'standard' on and the bouyancy one) -- 'string buoyancyUseCubeNamed = "" ' is one of the fields in the Part class -- specify your custom bouyancy drag cube there. Also in the Part class there is a straight-plain-and-simple ' float buoyancy = 1.0f ' field that can be set (maybe?) through config. I'm assuming this is a multiplier, and if you want the part to sink you would set it to a value < 1.0. (all of this API information was scraped from the public API docs -- https://kerbalspaceprogram.com/api/class_part.html )

Good news on the updated shader front -- it so far all looks like it will work out well. It does result in an absolutely massive shader package (~2mb), and crazy long compile times, as Unity internally compiles variants for each potential keyword combination (1300+ variants with the current # of keywords; grows exponentially with each added keyword feature). But it does work, and should offer some minor performance benefits when features are not used. Also made good progress on a new recoloring shader variant that works so much better than the existing options as far as consistency of recoloring between parts. It uses additional user-provided input textures to extract the 'detail' from the original diffuse/specular/metal textures, while discarding the base color / level data. The result is a much more consistent color output for the presets in the GUI (depending on the accuracy of the user-provided 'normalization' textures). For an example, here is one of the stock parts using the new recoloring shader, along with an SSTU tank, both using the same 'green paint' preset color from the GUI (I created the normalization mask for this part, based on one of @Manwith Noname's recoloring masks; is also using that recoloring mask for the section layout). This new shader was all geared to be part of the KSP 1.5 update -- but I'm close to having something available and usable now. Might have a version available for testing and feedback by end of week/the weekend. Still a few of the new features to add and clean up, but the existing features have all been transferred and appear to be working.

Indeed I did. Baked the surface out to a set of normals... and now have it as another option for tracks (I'll investigate using it for a wheel as well at some point) Also unified all of the tracks UV mappings, so that they can use a shared set of track textures. So should be able to use texture-switching to change textures in the editor.... Might be viable for wheel texture as well? Four sets of textures so far... might be able to come up with another 1-2 from the assets I have.

One more model imported and updated and with basic textures applied. Had to redo the vertex weights on this one for the skinned meshes, but now that I'm getting used to the tools it isn't taking too long.

Yes, at least it does in my testing. Its not a direct 'color multiply' type of AO as is commonly used by legacy rendering -- the shader uses it for lots of different functions such as decreasing specular lighting and fresnel on AO impacted areas. Yep, you can un-install the mod. Problem solved. No more warning dialog. Or tell SQUAD to fix their openGL/DX11 support. Or tell Unity to fix their DX9 cubemap blurring. Or... TU is open source -- feel free to fork your own version and compile it without the warning... but I'll offer absolutely zero support for forked versions (and forking of an active mod always leads to drama). Those are really the only options I can offer. Edit: @Burning Kan The one exception to the above would be that if you can show me a mod that is using TU, but not using any of the shaders. The DX9 problems only arise when trying to use any of the advanced shader functions; if there is a mod using TU only for model loading (one o bcink's?), I would be willing to investigate a solution for those cases.

Working on setting up some of the materials that I'll be using on the parts. Once I get the materials configured, should only take 20-30 minutes per model to get the textures done -- set up the masks for the main materials and effects (what parts of the model they effect), setup any part-specific details such as bolts or decals, and hit the export button. Should give extremely consistent results across parts as far as colors and any other effects applied to them... as well as being easy to setup. This is the new base rubber material to replace the placeholder that I was using, with configurable age-wear (enabled in image) (zoom to see details): Also experimenting with various masking and weathering effects, such as rusting... (can see some in the image above as well) Not sure how weathered the finished parts will be, so I'm building the weathering effects into the material stacks as toggle-enabled and configurable for different levels of wear.

Actually a bit of work from last night, but had to take another pass at it today to figure out the radially-wrapped text... Will also be a few more details/colors on this in its final configuration. Current text is just for testing... will likely have different wording/etc when done. ... Actually had to break out Substance Designer today to make new math functions to wrap that text around Yay for configurability in the tools I use (although it boggles my mind that a radial wrap function didn't already exist....).

Hmm... thinking I might rework the mesh on these wheels a bit -- they are 3.5k tris each. If I bake the normals on to a standard 24 sided cylinder, I can get them down to ~400 each... The original just seems a bit excessive for such a tiny part. Testing playing around with normals baking a bit.. left is original mesh, right is baked normals on a simplified mesh. Obviously there are notable differences due to how extruded the original geometry was, but I think it still conveys the intended impression quite well. (note I have not fixed the inset center hub on the baked version; it too could/would have an inset, as that geometry is fairly cheap)

Yay for outdated Unity documentation Hmm... knowing that.... I might do some experiments wrt KerbalFoundries/KSPWheel, to see if I can use that component for some wheel-tracks as a built-in (alongside the existing dust effects and sounds; might as well get the whole package...).

I can confirm that stock does exactly that.... Worse yet, there is some sort of stored heuristic value that can make the 'spring force' for symmetrical counterpart wheels have very different values depending on how the craft was driven previously. I've been able to 'abuse' that function to get a symmetrical and balanced craft to tip over just from the wheels difference in spring force. (e.g. if you constantly do a left-hand turn, compressing the right-side wheels for an extended period of time, and then return to straight driving or stop entirely -- your craft may no longer sit level, as the right side wheels will have a higher spring value than the left; it will, eventually, return to balanced... but still... absolutely not a physically accurate wheel simulation) Actually -- they do. Having played that game for quite a few hours, I noticed that while the wheels generally behave better than in KSP, many of the same underlying glitches are still present (I can easily make craft in TT that just jitter/bounce all over on their wheels). What they don't do is pogo, or launch stuff into orbit -- I think Better? Sure -- but they also do another thing I've long said KSP should do -- have a single rigidbody for the entire vehicle rather than one per part. It is this one-per-part rigidbody setup, with joints connecting everything, that make the wheels in KSP so unstable. It is a Unity engine problem though, and can be easily duplicated in the Unity editor with very basic testing rigs.

Sadly SQUAD has not provided us with that ability. You can try importing the .mu into Blender, and then exporting that or an fbx into Unity... ^^ is why I don't play with stock/other peoples models. Too much hassle and drama....

More playing around with Substance Painter -- (the black circles are counter-sunk black-oxide bolt-heads; sadly they don't come across the best in the image, but have a bit more detail when viewing the model in 3d) Before I start working on these textures in earnest I'm going to take some time to set up the specific materials that I'll be using across all of the parts. Should result in some extremely consistent coloring and texturing; the only thing that might be off a bit would be texel density, due to the UV map setup for the parts and the limited selection of usable texture sizes (^2 only....). And... once this is all said and done, I currently intend to host all of the model and art -development assets- online so as to provide examples for others wanting to do wheels/tracks/SP textures. This would be all of the .blend, .spp, and resource files used in the development of the models. Perhaps even include some documentation on some of the less-obvious quirks of working with this stuff in KSP.

Very true -- they look out of place compared to the parts using the legacy (stock) texturing. Not much I can am willing to do about stock parts sadly.... (others are working on the problem though). Which is why the PBR textures, if I even release them, will be as an optional extension to Kerbal Foundries. I fully realize that most players don't use TexturesUnlimited, that many actively don't want the change in shader/graphics for various reasons, and I'm not here to push an agenda for the shader changes.

Good for stock players, but shouldn't effect KF parts in the slightest. We don't use any of that stock black magic wheel module stuff around here More playing around with model updates and such. Mostly just verifying that the models are ready for texturing - I'm literally just slapping layers and effects on these things with default settings, and not really taking any time on them.... yet. But I like showing things off, and so far the textures seem like they are off to a good start, and will work out well when I get to really working on them. Here is today's reworked model -- Edit: Because I'm sure a few were wondering how well this stuff actually transfers to in-game -- pretty darned well (and easily too...):

It really shouldn't, and you have a valid point. That is why I suggested either putting in a PR, or opening an issue ticket with specific suggestions for the values. I'm more than willing to adjust and change values in places where the balance seems off. There is actually a ticket open already with some balance related feedback that will be taken into consideration before the next release; feel free to put your suggestions there, and I'll give them the same consideration -- https://github.com/shadowmage45/KerbalFoundries2/issues/36 Please be as specific as possible, both in what parts you are referring to, on what values need adjusted, and on what you suggest might be a good new value. The more detailed info I have, the better. Providing comparisons from stock/other mods is acceptable and welcome. I always assumed it was made with solid construction of the same super-dense materials that some of the other parts are seemingly made of I don't remember seeing that as a problem when I was first updating them for the new plugin, or if it was I fudged it in the configs. Will keep an eye out for it when I'm verifying/re-rigging and redoing the model exports though.

Its not intended to be read -- this is more of a prototype so that I can figure out the workflow and material settings for specific effects than anything else. The finished product likely won't even have any text on it (not a fan of text decals for many reasons...). But... noted... if I put text on it.... erm.. nvm. I'm jut not putting text on stuff

That is exactly correct. You cannot have zero-length suspension in Unity engine for wheels -- the suspension is needed to drive the rest of the simulation. Likewise, very short suspension throws will also be jittery/unstable... You might be able to get away with something like 0.1m of suspension, on a very light craft that will not be driven aggressively. Any less than that though, and the simulation starts to break down due to the discrete time-stepped nature of Unity physics.

Nice to see you stop by once in awhile Thanks, and will do. Yeah, you did send me quite a bit, quite possibly everything. Apparently there was a Unity .package that I hadn't unpacked before that contained most of the models and scene files (IDK, I must have thought it was a single scene or something). Been spending the past few evenings going through it all, importing models into blender, verifying rigging, getting the models cleaned up for (re) export through PartTools. Been wanting to update the models for the changes to Unity and plugin code for a long time... and figured I might try working through some updated textures while I was at it. I'm getting to know that feeling Only so many hours in the day, and can only be in one place/do one thing at a time...

You are certainly titled to your opinion; but there is a reason those patches are 'unsupported' and not included in the normal downloads. I asked for feedback on them multiple times (esp. in regards to balance), and got...well.... not much useful data. So I stopped trying to work on them. The patches worked well enough for the craft I design, and I never use stock craft files (don't even have them enabled; often delete the files entirely) If you really want to see them fixed -- the PR button is right here -> https://github.com/shadowmage45/KerbalFoundries2/pull/new/master Or, open up a new issue ticket if you would like to discuss the balance changes -> https://github.com/shadowmage45/KerbalFoundries2/issues/new

More testing/feedback preview work on PBR texturing. This time on a bit of a simpler part... (still just preview testing work; not doing much more than slapping on some materials and setting masks and really basic effects; if I decide to continue down the PBR texture path, the finished products will be more refined) I'm trying to keep the existing feeling of the Kerbal Foundries textures -- well used industrial machinery. Not 'new' by any stretch, but not rusted or abused either. Functional wear and gentle weathering. To give a peek into the setup of something like this, here is a rough overview of the materials and effects used -- Steel undercoat for the base, arms, central axle, and body top and bottom caps. Smooth-worn edge damage on unpainted metal areas (backplate and arm) White paint on the top and bottom caps. Black paint on the central axle. Edge damage/wear on both. Yellow paint background, with black paint stripes. Edge damage on both (yellow scuffed to reveal white paint; black scuffed to reveal yellow/white depending on how deep) Carbon fiber radiator 'fins'.... Dark blue metallic, with aqua glowing emissive side panels (will light up/pulse when activated) Single text stencil on the top ('CAUTION AG-DEVICE') with minor scuff/damage. And, a thin layer of 'dust' buildup on the whole thing, most noticeable in concave corners/crevices

@vossiewulf actually informed me of its existence and capabilities. It is however, not as useful for 'legacy' textures as are used by stock KSP and most mods -- it is far more intended to be used for PBR texturing. You -can- do legacy textures, but the problem is that many of the built in 'materials' don't support the legacy outputs. It is quite a beast of a program, and completely changes the way you approach texturing. Its much more like actually 'painting' on the model than standard PS based texturing work; you layer on 'materials' (such as metal, then paint, then dust), and apply effects to those for specific outcomes (edge wear, dirt buildup, etc). Did I mention that it is -fast- for most things (after you figure out your workflow and desired outcome)? With a bit of effort you can even setup standardized material sets + effects that you can just drop onto a model and go; set things up initially, and then it is as close to 'single-click texturing' as you will likely find anywhere. The downside -- it is a licensed application, and not cheap; there is a 30 day trial, but after that you have to fork over for either a monthly sub (~$20 for a SP + SD + B2M pack), or buy it outright (~$300?). So, for that alone, I would only recommend it to someone who does a lot of texturing work. But if you are spending even a few hours a week doing PBR texturing I would say it is well worth the cost; it took me from 'absolutely hating texturing work' to not really minding it so much.

Thanks So far it was just a quick 5min job in Substance Painter... but the results are already quite good. Will likely do another pass on it this evening to finish adding a few more details, and clean up some of the inconsistencies (need to provide AO/thickness bakes for SP to use...). Took far longer to get the model workable from the resources that I had. DAE models are... strange; I'm not sure what application they come from, but they apparently don't import into Blender very well. Lots of issues with embedded texture names or somesuch; have to edit the model files to remove all of those references before I can import them. I have no idea why people ever thought it was a good idea to embed texture-related anything into binary model files...but KSP does the same; if you were going to embed anything texture related into the model, they should have embedded the -entire texture- (which would be hard to 'break') rather than just a name/path reference (which breaks simply by changing a file-name or folder structure). Going to work on converting and re-rigging (at least) one model per day for the next few weeks. Once all of the initial models have been converted, I can 'fix' the scales on them all (make the model scale = what is desired in game), at which point I can start working through the texture updates / possibly new textures. If there are any model/texture related issues with the existing parts that anyone would like to see fixed -- either report them immediately, or they will not be fixed.

This is a two part problem. The first part of the problem is likely small inconsistencies in some of the part config compared to the models; a minor difference in some size/length specifications. This is something that I can fix, and will be looked at for all models during the upcoming model refresh pass. The second part of the problem, and the far larger of them, is the stock terrain colliders -- they often do not match the visible terrain mesh, and are off by a few (dozen...) CM. This is likely what you are seeing, and it is different for consecutive launches of the same vehicle -- sometimes the wheels will sink, sometimes they'll float a bit, and sometimes they'll look exactly like intended. There is zero that I can do to fix this problem. Note that it also effects the stock wheels, kerbals, and standard part collisions because it is the actual terrain collision meshes that are misplaced.