Search this Topic:
Feb 21 11 6:01 PM
Feb 21 11 6:28 PM
>> The problem has origin in the resize_image function...
Just a short tip and without understanding any and all of the code in wings_image.erl (in fact I don't understand most of it ):
There is for sure a reason, why the function wings_image:resize_image/3 is NOT exported, though it looks so useful to have. See, how it is called there: only after heavy check of the capabilities of the OGL card/driver. Maybe you can find an exported function in that module (or some other) appropriate for your task?
Feb 21 11 6:39 PM
Feb 21 11 6:43 PM
Feb 21 11 9:15 PM
here is the updated German translation. One suggestion for the English version checkbox: "Keep aspect ratio".
I like, that you were able to change the code to make a grid-like object with clean bottom and side faces. This makes some things really easy. E.g. mirroring/freezing the object ground face (see the fence sample earlier and Ran13's suggestion) is a snap. Also mirroring the side faces to have a bigger terrain comes in handy sometimes. And finally selecting the top faces to UV map with a height texture: just (Space), (F), then select the -Y ground face, (+), (Crtl+Shift+I).
But may I point to my message #61? I really would like to have an option/checkbox for the sides inner edges (NOT marked hard), because then the smoothing is better (if one wants to make them hard, one can just Edge Ring (G) them). As is, these strange Catmull-Clark artifacts (gray faces) show up and I found no quick/reliable way to create the vertical edges by hand.
Regarding the options dialog:
In the "Image Info" section I would like to see the "Original" info and the "Used" info, because your plugin in the meantime eventually processes the chosen file more or less heavily. See, when I choose a 2048x2048 image and you scale down to 384x384, I wanna KNOW that. Ditto, when I choose a RGB/3 channel image with R,G,B channel values all the same, you correctly interpret that as greyscale, but again I wanna know about that fact. And finally, the name (maybe part of the path) to the image should be shown too in the "Original" section.
Besides, restricting width/height to 384 isn't always a good choice. When I earlier considered 384x384 a good and practical limit, I really meant a 384 * 384 = 147,456 pixel limit. Why not allowing "sort of a wall" by having a 1024x4 height map image? That would be only 4096, easily handled by Wings.
The ability to specify upper and lower limits is really nice. And your cuts seem to work very well, flattening out excess/unwanted values in the generated terrain. The gray scale sliders are also really straightforward and IMO understood/usable by anyone. However the color sliders are really hard to set/interpret, unless one knows, that they are meant for DEM data/coloring. And because they are "the other way around".
And I imagine a numeric input and a color picker (as in the stock color dialog of wings, which obviously can be called from any other dialog). That way, one could pick up lower/upper limit just from the preview. Sorry for misleading you, to have the sliders directly in your dialog. For consistency and the color picker feature I ask for a numeric entry accompanied by a color field to the left (which calls the color dialog). Besides, as in ANY dialog in Wings expecting numerical entries, one can enter some formula into the field; say one needs "cyan", having a hue of 180°, one can enter "180/360", pure yellow is "60/360" and "25/360" is orange with a small bias to red.
I also tested with this hue scale image made with GIMP.
It is a good test image, 360 pixels wide, essentially each pixel column has one degree more of hue (though it is not perfect, some few cols have the same integer hue, while the RGB is different). When I generate a terrain out of that (sliders at the ends) I get this object:
Note the wiggly contour. I expected just a straight ramp. Why is this? Micheus, did you just use the exported Wings rgb_to_hsv function, or did you some weighting (maybe required by DEM data/coloring)? If so, that MUST be documented. Else, there is an error somewhere. I can't believe, that it is in GIMP and neither believe it to be in Wings.
Also a close look at that object shows random height differences in areas, where the map hasn't these:
Some few edges highlighted, that SHOULD have been horizontal, but ain't. Again, if this is a hidden feature of the plugin (randomizing height just a little bit makes sense, when generating terrain), I would want to have that documented (and an option to turn it of).
So far today, many thanks for your work, best regards, Georg
Feb 22 11 3:42 AM
Mar 2 11 2:10 PM
Mar 4 11 2:59 PM
Mar 4 11 4:30 PM
Mar 4 11 5:31 PM
Mar 24 11 9:51 AM
New release (build 17) - 4Shared or Windows Live SkyDrive- fixed image preview problems reported by oort; (post #77)- added text fields enable the user enter values for high and low cut fields based in percent of the Height value you have entered (deerwood's suggestion);- added options to enable the user to decide about the edges in the side and bottom faces of the mesh;- added option to use or not the hard edges (deerwood's suggestion);- sliders used to set cut value are now positioned in accord with low and high values found in the heightmap data;- information frame now shows the original value beween parentesis when the image was changed (deerwood's suggestion);
Mar 24 11 7:54 PM
Mar 25 11 4:10 AM
Mar 25 11 1:00 PM
Mar 25 11 1:18 PM
Mar 25 11 1:27 PM
Apr 13 11 3:57 PM
Apr 13 11 5:13 PM
Apr 13 11 5:20 PM
Apr 13 11 5:21 PM
© 2017 Yuku. All rights reserved.