Started by Erwin0265, November 03, 2014, 07:35:41 pm
QuoteIt would be much better to my mind if you just add new replies, it doesn't look impatient, we know what you intend. Otherwise it gets confusing if you change a post I later replied to, just to add new information that my reply does not reflect.
QuoteFirst, the clipping issue (left/right bracket keys, i.e. [ ], where right bracket *increases* the clipping plane distance). The reason this is useful/important is because Terragen portrays a *tremendous* range of scales, thousands or even millions of kilometers, all the way down to centimeter/millimeter scale. This requires high numerical precision to represent accurately and so requires lots of digits, i.e. 32 bit (or greater) precision. The problem is that the OpenGL z-buffer (depth buffer) has more limited precision, or at least historically has (I'm not sure if they improved it), and so when we display *in the 3D preview* (which uses OpenGL, while the main renderer does not), we are limited by that lesser precision and must specify a *range* of our total distances to represent in the 3D preview (i.e. the entire range cannot be accurately represented with the number of digits provided by a typical graphics card z-buffer, so we show a portion). The clipping plane adjustment settings change the bias of that range, either closer (so that you see lots of small stuff, accurately, but it clips stuff really far away), or further (so that you see really, really far, but it clips stuff closer to the camera). By default we have it set to what seems to be a reasonable range.
QuotePlants *on* the surface: you need to make sure the anchor point for your object is at the point of your object that you want to be on the ground. TG has no other way of determining the boundaries of your object.
QuoteIt's a shame that the Xfrog library models are not the same as what Xfrog software outputs in terms of default scale,
QuoteI would guess maybe they're less popular because of the potential confusion between decimetres and decametres. Who needs them anyway?
QuoteIn the early days of TG development I was working with a company that had standardised much of their pipeline around decimetres, but they were working in Maya with Maya's units set to centimetres. So Maya would call something a centimetre but the artists were building things at the scale where it was a decimetre. This is where the bug originated in Terragen. I thought I was scaling to centimetres, but accidentally scaled by 0.1 and never spotted my error because it just worked. At that point I hadn't twigged that the pipeline was treating centimetres as decimetres and that my code wasn't doing what it said it was. Later on when I added support for XfrogPlants OBJs, the incorrectly named "Source in cm" seemed to work correctly, again simply by accident.
QuoteDeciliters though is very common as a regular bottle of beer contains 3 dL
Quote from: Oshyan on November 04, 2014, 06:36:24 pmand then changing the label of the present "source in CM"
QuoteIt's good that unchecking Source in CM is doing *something*, but as Matt explains it may be a known bug if it's not working quite right. If so, it would be a matter of simply changing by a factor of 10 I think, so at least it would be a known quantity. But indeed it is annoying, so *adding* an option for true "Source in cm" (see, lowercase! ) and then changing the label of the present "source in CM" to "source in dm" (dm?) should be possible, and probably a good idea.