Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Fil

Pages: [1]
Geology and Terrain / A challenge: htraE - Earth inverted
« on: January 21, 2013, 07:09:17 AM »
It's been quite a long time since my last post.. But I'm still alive! :)

I have a slight challenge for anyone to practice on!
I came across this artistic image of the Earth, flipped inside-out..  - How would our planet look if we changed "up" with "down"?

Really neat... HOWEVER: It's geographically wrong! :twisted: There should be a huge mountain range at the Mariana Trench, and a really deep area under Mount Everest.. Would anyone accept a challenge to see how the Earth would actually look like if inverted?
An extra challenge would be the night texture: placing of cities and city-lights along bays and flat areas near waterways!

Possibly, you could:
- find height-map of Earth including underwater region
- obvious use for an Inverter device
- one or two gradients could bias/threshold the application of slow to height, so that more snow appears near the poles
- creative use of weathering device to use as mask for the city placement
Sounds interesting, no?

By the way, "htraE" is Earth spelled backwards ;)

General Discussion / new worlds, comming this summer?
« on: August 17, 2006, 05:58:41 AM »
I'm posting right after taking part on a discussion about the new planets that may come into our Solar System..
Apart from the weird names of the new planets, I think it's good to refresh our view of what the Solar System is composed of :) I also agree that "a dozen planets" is easier to say than "nine planets" :) plus you can say "a dozen or so planets" to account for the other ones you don't know if are plants or not :D

Anyway, back to the topic..

I know this is not MojoWorld nor TG2, so i'm not asking for complete planets, but have you guys made some terrain with World-Machine that could be out of this world?
Could any of those be of one of the new planets that are coming to our Solar System this summer? :D
What would Caronte look like? Or 2003 UB 313 ? :)

Show'em here! :P

General Discussion / WM 1.2 Review
« on: November 25, 2005, 02:50:31 AM »
Hello verybody!

Some of you may be puzzled with the new features that WM1.2 brought along unexpectedly. Since these are not yet available in an help document form, I decided to write up a small review of them, as other people to for digital cameras and so on :)

So, imagine Wonika-Minolta made this WM1.2 digital camera, that has 1.2 MegaPixels(MP) - an upgrade from your previous 1.0 MP camera you had before!..

[the Camera]
The first thing that comes up to mind is "where are those new features that I read in the changelist?"
(I'm not going to follow the same order as that of the new features list, instead I'm going to go in the order that I think you'll find them)

[Snap to Grid]
Well, the first thing you notice once you run WM1.2 (right after the reg key messagebox ;) ) is that grid background! Don't worry, it's not squared paper to do math problems! :) it's the visible portion of Snap-To-Grid feature. Now devices can be aligned without effort. If you'd like to turn it off, just go to World Commands -> Prefrences -> Workview Options and uncheck Devices snap to grid. This will also hide the grid.

[Wiring Knots]
The next obvious difference are those "knots" in the wires.. Those are the Wiring Knots that the feature list mentions. Try them out! Let's say you have a Perlin connected to a Terrace device and want to put a Splitter in between. In the old days you had to disconnect them, and connect the Splitter (too much trouble). Now you can simply place a Splitter on that Wiring Knot, and it will automatically be connected! This works with devices comming straight from the button bar, device from the menus, or even devices that are dragged in the work view. Fabulous!

[Snap To Port]
So by now you must be wanting to build some network, no? Ok, let's do it! Let's start by creating a Radial Gradient and a Height Selector.. Now lets connect them! Do you remember how hard and tedious it was to wire devices together? Now the wire automatically snaps to the first available Port of the device under the mouse cursor! Go ahead, practice and you will like it! :)

[Device Display Hints]
So now we have a Radial Gradient connected to a Heigh Selector, but wait! What is that on the mini-preview ?? The radial Gradient had that nice green 3D landscape in the preview, now the Height-Selector has a Black Dot on a white square? What is going on?..  That is the "Device Display Hint". Devices now can hint their purpose in the previews and in Explorer View (BTW don't go into Explorer View yet ;) )  A black and White image will correspond to hinting a mask, and the usual customizeable colored look to hinting a heighfield.
You can manually set it in the right click menu on a device, or Device Commands -> Set device display hint. You can choose between Normal (which is the device's own default), Terrain, and Mask. If you set it to Terrain, you will have a green border arround the output Ports of that device. If you cchoose Mask, you will have a brown border. Inexistence of border, means "Normal".
Devices as the Selector devices typically are to be used as masks later on, so that is why they now output the hint of Mask by default!
This hint will travel along the network and will be kept until you specify a new hint, or until the device overides it. Most often, the Mask hint will end up on the third input Port of a Chooser device... But the Chooser will propagate the hint information from the first input port, as most devices will.
Hints have absolutely no influence in the heightfield computation and device building. They are there just to help the user in reading the purpose of the devices.

[Local Coordinates]
Ok then, now select the radial gradient you created earlier and let's take a look at explorer! What are you expecting to see? a lot of hills? Yeah.. So was I!!.. Prepare to be amazed!       ...One?!? only?!?..
That's it!.. How many times did you want to create a lonely island in the Pacific Ocean before, and then went to explorer and all you saw were an infinity of islands, which have nothing to do with "lonelyness"? A guy wants to be alone in his vacation (ok, maybe alone with his spetial girl) but not accompanied by other turists in other islands!! :)
Now you can finally create a single island just for you (and your mate)..  But.. err.. what if you really wanted the old behaviour?   Let's go back and define the Radial Gradient's Properties.
The properties box was also changed. a lot of devices (typically in the Generator familly) allow you to specify a location in the world! In the top left corner, you can see a "Transformation" area that allows you to specify the coordinates of the center of that device's effect. You can specify it to be relative to the World's coordinates, or to local coordinates. WM1.0 worked in local coordinates, that means each tile had this radial gradient centered in them, so you would have a lot of gradients tiled toghether in explorer. Now, if you choose "World", you only have one gradient in this world :). Doing this will also enable you to specify a radius grater than 1 :-o! This will allow you to get a larger lonely island for your vacations ;)

[Auto selection of pasted devices]
Some time in the future you will also like to Copy&Paste large networks. Previous versions had a problem here. you copied the entire network, but when you pasted it, you had to select every single device again to move them to their final place. Now when you paste anything, it is already selected for you, so you can move it right ahead!

[new file input features]
Now, the File Input device suffered some improvements too. I'm not going to go into great detail with them, as I feel I haven't practiced enough.. But they give you more control on the scaling of the terrain, and behaviour at the borders.

There is a bunch more of features in WM1.2 but I won't spoil you the fun to discover them! I'll give you some clues: it comes with two new macros! I haven't had much time to play with them, So I can't comment on them, but you may like to take a look at them ;)


No review is a review if you don't say something in the end like "This camera sux" or "this camera is excellent!".
But ofcourse, to look realistic and convincing you need to point out some drawbacks too ;) If you point drawbacks, you get to be regarded as someone with greeeeaaaat guru experience in the matter and be venerated for the rest of your life!..... (No harm in trying :P)

World Machine 1.2 is rather recent, and so it doesn't yet have a completely available documentation. Also you can't run plugins from v1.0 without getting the recompiled versions to match v1.2..  But the only plugin that I know of is my LEGO filter, that very few people seem to have used..  So unless you are building LEGO blocks in WM you really don't need WM 1.0 as much..

[Veredict ?]

Now for the thumbs up/down part!
I recomend WM 1.2, as it solves some issues with saving files in the limits of memory usage, deals better with memory problems and that stuff. And that is why I recomend it. Ok it has new features, ok, the features really improve WM.. But I think the key aspect is that a lot of the troubles you guys had to go trhough in WM 1.0, are now fixed in 1.2. And I espetially like the way things are moving! It is a pleasure to see this program, this community, and this spirit grow healthy every day.

Have a great, decent, lot of fun with this WorldMachine, everyone!

Any quesitons? keep'em comming!

PS - I bet noone could pack this many features in a 1.2 MP digital camera as Stephen did ;)

Plugin Development Forum / Writing my own input/output device
« on: September 09, 2005, 01:25:10 PM »
Hi Stephen,

You said there was some things to writing an output device using the PDK that we should know about. What would those be?

General Discussion / New Device: LEGO Filter
« on: August 21, 2005, 01:38:48 PM »
Hi there!

You probably already heard of the PDK. Well I spent about a week using it to create a new device. A LEGO Filter, which makes things look like they are built of LEGO blocks :)

Check it here: LEGO

The zip file contains the LEGO Filter.dll to be placed inside your World Machine/plugins/devices/ folder. It also contains a LEGO example.tmd file that shows all the stuff you can do with that filter.

Oh, it took me only 2 hours to code the essential part of the LEGO Filter (rescalling and discretization of heights) but to put it working in explorer in perfection took me two or three days of work. So, when you see it in explorer, please try to get fascinated! ;)

Happy exploring,

Plugin Development Forum / PDK oppinion: LEGO Filter
« on: August 19, 2005, 02:37:40 AM »
I had the opportunity to play with the PDK for half a week. I have to say I found it easy enough to do things quickly. I do have some programming experience that helped the quickness, but it is nice. I spent arround two afternoons playing with the PDK trying to make a silly sinus/cosinus generator, got to know the PDK somewhat superficially.. Then I interrupted the easy trigonometric generator, and started to work on a more interesting idea ;) That is how I got to making a LEGO Filter. Below, is a screenshot. The basic working concept (without any user control (parameters) took about two hours to code up. Then adding parameters was easy.. But some bugs started appearing as divisions by zero and scalling issues came in to play.. That took about one day to overcome.. Then, the next day, I spent doing some upgrades and adding flexibility. Then, I stoped for about 5 days to take short vacations, and now I am back at it, to perfect it even more.. It works fine, though there are some tiny edges I'd like to polish.
Anyway this is what it can do:

So for time consupsion in making a device with the PDK, I think the core part is quick to do if you have your ideas settled. You then take some time in thinking what parameters should the user have access to. You then take even more time solving bugs. And the remaining 90% of the time, you spend in polishing things, as typical of any programming activity :)

Oh, regarding debugging, I haven't really tried debugging in the "normal way" yet, using a debugging environment. I used the "MessaBox" method.. Silly and anoying, but it was ok, for something as simple as this filter.

Ok, now for what this filter does: it grabs any heighfield and converts it to a pile of LEGO blocks :) You can choose the type of stud (flat plate, normal stud, technic stud, or optional heightfield: so you can make your own studs :) ) You can specify the size of the LEGO blocks, and you can use LEGO plates (1/3 the height) also. You can also choose 1x1 or 2x2 blocks.

It is not 100% finished yet :( I am trying to make things look right in explorer, as the blocks are discreet, they can look a bit disapointing for some parameter values, and I m trying to get the best possible compromises to have something that works and still looks good. Soon I'll give you the plug-in, but for now, you have to content with the screenshot..

Happy PDK-ing,

General Discussion / How should a human model with height?
« on: March 11, 2005, 12:27:42 AM »

I bring you a question (maybe more of a subject for discussion, if you will) about modelling. It's related to managing height when modelling a terrain.
I find this topic similar to photography, as there is a certain "dynamic range" the analogic film or (digital sensor) is capable of capturing from the broader range of possible light intensities. So if something is darker than it can be sensed, or brighter, it will get cropped out.

modelling issues

Modelling a terrain is a bit similar, with the exception that we have the hability to shrink or expand the height in order to fit it inside the desired "dynamic range", but then we loose resolution.

So when modelling, how should we look at things? If I am modelling a beach, should I concentrate on seeing the the tiny dunes in te sand?
WM alows us to bother with that later, as we can use the Clamp device to scale the beach down to size.. But still, if I am watching a render of a "final" result, I should be aware that certain heights should not be seen as the talles peaks arround. For instance: near the coast, it is very likely that mountains are only 600m heigh, and only deep into the continent they get higher, reaching 4000m maybe.. However, If I look at the surroundings, they are probably only 600m heigher (ok maybe a bit more).
What I mean is that localy, the appearance feels the same, but globaly there is a difference. My question is about how should we conceptually deal with this, when modelling? How should we think?

I know we can make some sort of a blurry mask, that will automatically define a maximum height for mountains, but my problem has more to do with interpreting correctly a rendered image and determine whether the height is "adequate".

In my modelling, I tend to forget about the height value and then simply correct things in the end using a height scale that renders it better. This has the drawback that I mentioned above. I think I just discipline myselft to make things right when the time is right.. I just need to know when that is :)

representation issues

If in the end I come up with a terrain that has a beach, with tiny dunes, then some plains, and hills and mountains with high peaks, I will most likely have lost resolution for the dunes.. Is the only solution to this (using heightmaps) to use higher bit-count: 32bits, 64bits and so forth?

Regarding terrain representations, this topic can also be found in some types of files. For instance DEMs are heightmaps that specify a reach between two height bounds. The files says that the lowest point in that heightmap is 1000m and the highest is 3000m, for instance.. This specifies the "dynamic range" of the data, and distributes the full resolution to that section only. This may cause problems if two tiles of terrains are put aside of each other, as they could have different height resolutions. but that is a different matter, that can be solved with some nice sewing.

I think I will stop here for a rest.. :P

Plugin Development Forum / Some light on "what is the PDK?"
« on: February 28, 2005, 06:14:05 AM »
I decided to create a new thread here about this, so we don't clutter the notification thread too much, or place too much off-topic information there.

So what is the PDK?

Well, I'm not the best person to answer that, but I can start providing part of the answer that I know..

PDK is the "Plug-in Development Kit". It allows (will allow) someone wth some programming knowledge to actually make a plug-in for WM. A plug-in could be a device, for instance.

So what is the benefit of a device made as a plug-in over a macro?
A macro will use devices and functionality available in WM. If new stuff needs to be made, the only way to make it is with a plug-in. Imagine you want to do some sort of wind erosion, where you specify a direction for the erosion to go. There have been some attempts at doing that in macros, but they were not very sucessful, or limited..
with a plug-in, you have access to more information and operations that allow you to manually decide what to do to individual height pixels.

As for other application to plug-in making I can't say much for sure, as nothing has really been defined anywhere yet. When the PDK is ready, everything we need to know should be available.

Macros and Plugins / Beach Macro Uploaded
« on: April 22, 2004, 10:48:12 AM »
I just placed a new macro for making beaches in my small WM web-space..

Check it here: Beach


Pages: [1]