height field to sphere?

[xoxos]

i don't see that as the challenging part.. my awareness of voronoi alg is cursory.. my conception was that each pixel is checked against n number of points and the distance relative to them is used (i assume taking the ratio of the two closest points would suffice). i'm sure several methods would work for distributing a desired number of points fairly evenly (eg. even equidistance along latitude with longitude randomised on the equirectangular map would still appear fairly random and could take some elementary improvements).

using the outcome to reduce the height field along edges would break up ridges, but going to the bother of improving the algorithmic model at all versus manual editing would invite continuing into developing the height field along continental seams.. and the amount of research there doesn't interest me :p

[Hai-Etlik]

i don't see that as the challenging part.. my awareness of voronoi alg is cursory.. my conception was that each pixel is checked against n number of points and the distance relative to them is used (i assume taking the ratio of the two closest points would suffice). i'm sure several methods would work for distributing a desired number of points fairly evenly (eg. even equidistance along latitude with longitude randomised on the equirectangular map would still appear fairly random and could take some elementary improvements).

using the outcome to reduce the height field along edges would break up ridges, but going to the bother of improving the algorithmic model at all versus manual editing would invite continuing into developing the height field along continental seams.. and the amount of research there doesn't interest me :p

Ah yes, it would be a lot easier with spherical raster data, all you need is a spherical distance function. I was trying to find a vector algorithm which is a lot more complicated.

[xoxos]

got around to watching a bunch of tectonic animations yesterday. feeling more deterred atm given the complexity of the approach and the diveristy of theories on tectonic formation. will let it sit for a few days in case some fancy filtering method occurs to me, otherwise i'll proceed with manual editing..

[xoxos]

hehe.. this topic was resumed in another thread, but i thought i'd better continue it here.


discussion: me whining about my interpolation technique taking ages to compute on my non-top modern device. simplified interpolation was mentioned. it took about 3 minutes to make the modifications and try the alternative method.. documenting this to save other developers those minutes....


here's one octave rendered with fast and slow interpolation methods
interp1.jpg


8 octaves (first two octaves are unridged, subsequent are ridged)
interp2.jpg


..and just for fun, here's the fast interpolation without shaping the fractional component, as i've seen it described
interp3.jpg


pretty pictures any more serious developers are advised to investigate the simplex noise method.

[xoxos]

solved it!

adding a timer and a preview mode that renders only the pertinent octaves at a lower resolution. this should make it under a second even on my system say at 8x8, so that the globe can be 'spun' with the mouse.

thanks again to waldronate, i believe you'd mentioned a partial render and i'd noticed that wilbur uses a timer (still very new at this kind of task).

[xoxos]

....i didn't want to do this, but it looks like i need to in order to move forward.

i'm going to have to ask a win32 SDK question....

only had one more feature to add before posting for early feedback, should have taken 5 minutes..



alright - my app has a main window. a dialog is selected from the menu to set height field params. i wanted to create a second dialog that also opens from the menu to set params associated with water. i haven't created a windows app with mor ethan one ancillary dialog before.

despite providing a unique name for *every* variable associated with the 2nd dialog, when it opens it displays the same gui as the first dialog. i can't seem to discretise it, even by going to silly lengths to provide a different name for everything.

certainly, i understand it less now than i did an hour ago (...)


so.... perhaps someone can guess where i've erred from that. otherwise, here's the horrible-to-pick-through code... as you'll observe, every hwnd et c. has it's own silly name... i've also tried using different #'s for the WNDCLASSEX wwc = {0}; statement to no avail. it compiles, it just shows the same panel on both dialogs.

/////////////////////////////////////////////////////////////////
////////////////	HEIGHT FIELD DIALOG
/////////////////////////////////////////////////////////////////

LRESULT CALLBACK HFDlgProc( HWND hdlg, UINT msg, WPARAM wParam, LPARAM lParam ) {
	hhfdlg = hdlg;
	HDC         hdc;
	PAINTSTRUCT ps;
	HFONT		hfont;

	INITCOMMONCONTROLSEX InitCtrlEx;	//	for progress bar
	InitCtrlEx.dwSize = sizeof(INITCOMMONCONTROLSEX);
	InitCtrlEx.dwICC  = ICC_PROGRESS_CLASS;
	InitCommonControlsEx(&InitCtrlEx);

	switch(msg) {
//DELETED DOESN'T MATTER
	}
	return (DefWindowProc(hdlg, msg, wParam, lParam));
}

void RegisterHFDlgClass(HWND hwnd) {
  WNDCLASSEX wc = {0};
  wc.cbSize           = sizeof(WNDCLASSEX);
  wc.lpfnWndProc      = (WNDPROC) HFDlgProc;
  wc.hInstance        = ghInstance;
  wc.hbrBackground    = GetSysColorBrush(COLOR_3DFACE);
  wc.lpszClassName    = TEXT("DialogClass");
  RegisterClassEx(&wc);
}

void CreateHFDlgBox(HWND hwnd) {
  CreateWindowEx(WS_EX_DLGMODALFRAME | WS_EX_TOPMOST,  TEXT("DialogClass"), TEXT("Height Field"),
        WS_VISIBLE | WS_SYSMENU | WS_CAPTION , 0, 21, 192, 285,
        NULL, NULL, ghInstance,  NULL);
}










/////////////////////////////////////////////////////////////////
////////////////	WATER DIALOG
/////////////////////////////////////////////////////////////////

LRESULT CALLBACK WaterDlgProc( HWND hwdlg, UINT msg, WPARAM wParam, LPARAM lParam ) {
	HDC         hdc;
	PAINTSTRUCT ps;
	HFONT		hfont;

	switch(msg) {
//DELETED DOESN'T MATTER
	}

	return (DefWindowProc(hwdlg, msg, wParam, lParam));
}






void RegisterWaterDlgClass(HWND hwwnd) {
  WNDCLASSEX wwc = {0};
  wwc.cbSize           = sizeof(WNDCLASSEX);
  wwc.lpfnWndProc      = (WNDPROC) WaterDlgProc;
  wwc.hInstance        = whInstance;
  wwc.hbrBackground    = GetSysColorBrush(COLOR_3DFACE);
  wwc.lpszClassName    = TEXT("DialogClass");
  RegisterClassEx(&wwc);
}

void CreateWaterDlgBox(HWND hwwnd) {
  CreateWindowEx(WS_EX_DLGMODALFRAME | WS_EX_TOPMOST,  TEXT("DialogClass"), TEXT("Water"),
        WS_VISIBLE | WS_SYSMENU | WS_CAPTION , 0, 306, 192, 285,
        NULL, NULL, whInstance,  NULL);
}

[waldronate]

Have you considered using DialogBox() or CreateDialog() to create your dialogs? That way, you can pass in the dialog resource ID as the second parameter. It's been a fair few years since I've done raw Windows programming in straight C, so I may be remembering it incorrectly, but you'll definitely need some way to specify that resource ID that you created in your .rc file.

[xoxos]

i don't use .rc files. the method i use is the only one i've found sufficiently documented. i own petzold but find 'programming windows' too windy and disparate to function as a reference, i simply cannot recall the contents of all 1200+ pages at once. my perception is that the method of the author is not intended to actually convey an understanding of the material either.

i resent that all win32 instructive material starts off building dialogs without using .rc and then switches to using them without fully documenting how to do things in the initial manner. borland fclt doesn't build them for you so i'd be at a greater loss attempting to use them.

it does seem to me that i've eliminated every variable as a discretisor, so i will have to address this at a greater scope (or simply aggregate all my params on one panel with a scroll bar).

[waldronate]

If you're not using .rc files, how are you getting your child windows created? Issuing a CreateWindow() call for each one? Painful...

I think that the window class name needs to be unique acording to window type. If you're using the same class name for two different windows, then you'll get the first (or maybe the last) on registered. So instead of creating a "DialogClass" class, create a "WaterDlgClass" and "HFDlgClass". The window class name is associated with your window procedure in RegisterClassEx(), so using the same class name will get you only the same window procedure (if that helps).



In your example program you're setting a TOPMOST attribute for your pseudodialog, which makes it appear on top of all other windows in the system. This behavior is a little disturbing...

[xoxos]

the intent was to keep it on top of the main window. the hf dialog creates its own entry on the taskbar, so it's not providing the conventional functionality i'd intended. i'll fish some more.

! well i'll be (i'll never run out of ways to feign surprise when presented with more information about how this sdk is intended to function..) i had presumed the string "DialogClass" registered it as such, in the same manner as "button", but you're right! it can indeed be modified. doing so on the water class resulted in the dialog disappearing.. so that's something else i can fix, but some other night)32wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww wwwwwwww32

(kitten)

yes on CreateWindow for each control. it's been fun using a minimal compiler (while simultaneously being a stubborn 'purist'). the internet is starting to have the referential mass required to actually support it. only took a decade

once again you have taken time to provide assistance i would not have been likely to receive otherwise. anytime you want those vst licenses... :p thank you!