• Welcome to World Machine Community. Please login or sign up.
September 17, 2019, 12:00:02 pm


Read the Development Diary for an inside look at World Machine's progress!

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 - Eric Cosky

Development News / Feature Requests
July 08, 2011, 08:16:15 pm
I saw on the blog the solicitation for feature requests so I thought I'd just make a post here to communicate things I think might be worth doing/having in World Machine.
I am an admitted newbie to World Machine, so please forgive any dumb or otherwise useless suggestions I might have. I fully recognize some of these are pretty unlikely to happen but perhaps you will find the ideas useful in some way regardless.

* Drag & Drop images from windows explorer to create a prepared file input device. This would just be a convenience of course, but a handy one.

* A way to view the hires tiled output within the viewer. It seems that only the regular builds are visible in the program itself.

* In the device view, when using mouse wheel to zoom, zoom in on where the cursor is.

* Make the various device modal dialogs non modal. It's mildly annoying and at the least, time consuming, to have to tweak and then close a dialog to see the results.

* I suspect this program could greatly benefit from having the devices written to use CUDA. It's already pretty quick, but it could possibly be orders of magnitudes faster due to the parallel nature of a lot of the work this kind of app does.

* Render farms on a per-tile basis would of course be very useful. This could be done as a service listening to a port, which is sent a .tmd and a tile coordinate to render, returning the results to the PC running the UI. Doing this over a LAN is not as bad as it might sound if using named pipes, btw, but making it work over the internet as a peer to peer service would be ideal. Blender has something along those lines, and it's pretty amazing.

* It would be interesting/useful to see an icon over each device that is the preview for that device. This is similar to what Softimage's Render Tree does for shader nodes; it's an optional display toggled per node.

* It would be nice if the color generator nodes had a display for the color they are generating. This need would be served by the icon display (above), but if the icons aren't going to happen this would be pretty handy.

* At least a few of the nodes do not have their ports documented. It would be nice to see this fixed. For instance, I have no idea what the "Mesh Output" node's "Mesh Mask (Heightfield)" input does. Being a bit new to the program I wonder how many undocumented ports there are.

* This one is a stretch but I thought I'd throw it out there just in case: Have mesh output generate a user specified number of LODs for a tile, with 3 variations on the edge stripping for each side, allowing a renderer to select between them at run time so adjacent tiles can have different resolutions without gaps in geometry. The variations would be LOD+1, LOD+0, LOD-1. As you no doubt know, this is something terrain engines rendering static geometry often have to manage one way or another, but your program in uniquely positioned to solve the data generation for this task. The same logic that generates this data could be used to improve the realtime display. (I'm going to have to implement this for yet another terrain engine is why I mention it.. would be nice if the tools could take care of that instead).

* It would be useful if the mesh output had a resolution division parameter. This would allow a normal & color map to be generated at, say, 1024x1024, while the mesh is generated at 128x128 (and then possibly reduced via triangle reduction). Having triangle resolution match the color & normal map resolution pretty much mandates further processing of the mesh since color & normal maps are always going to be at a much higher resolution than the geometry.

* Provide nodes that are resolution multiplier/dividers. When pulling data from devices with a different resolution, filter or interpolate the input data as needed. Basically, I'd like to use images (such as tiled images of foliage) that are selected based on slope and other settings from a heightmap that is relatively coarse, where the images are at higher resolution than the heightfield itself. If each node had the ability to override the resolution it seems like this might fit in with your current scheme without breaking everything.. just guessing, of course. If this were a part of the system, the mesh division parameter mentioned above wouldn't be necessary because the resolution reduction could be done as part of the node graph using a resolution divider node.

Thanks for reading-
Nothing major here, just wanted to let you know about some minor bugs in the tiled build progress window. It doesn't appear to affect functionality, it just isn't showing accurate progress information.

In the attached pic you will see the tiled build progress window.
The number of heightfields used is in the negative, and the number of active threads seems wrong ( >100%).
At one point, the progress column for all tiles was at 100% yet there was still a lot of work going on.
Also, the green progress bar sometimes went backwards.

In the attached scene, the exported OBJ files do not appear to have had triangle reduction applied. I get the same results with & without the reduction turned on.

If I've configured the scene incorrectly that would be good to know but it seems to be set up as required as far as I can tell.

Development News / Tiled mode crash, scene included
July 07, 2011, 11:36:19 am
Crashes both 64 bit and 32. Attached scene. Load scene, hit 'tiled build'. It does some work then crashes.

Attaching debugger to 32 bit gives me this stack with a null pointer exception:

>   CustomDev.dll!100a9c57()    
   [Frames below may be incorrect and/or missing, no symbols loaded for CustomDev.dll]   
   World Machine.exe!0048c7b6()    
   World Machine.exe!0048c7c3()    
   World Machine.exe!0048cce9()    
   World Machine.exe!00554de5()    
   World Machine.exe!0048c1ab()    
   World Machine.exe!0048c29d()    
   World Machine.exe!00537833()    
   World Machine.exe!004534cb()    
   World Machine.exe!0046d426()    
   World Machine.exe!0046d4cb()    

100A9C3C  jg          100A9C48 
100A9C3E  mov         ecx,dword ptr [eax] 
100A9C40  mov         edx,dword ptr [ecx] 
100A9C42  push        eax 
100A9C43  mov         eax,dword ptr [edx+4] 
100A9C46  call        eax 
100A9C48  cmp         dword ptr [ebp+0C4h],1 
100A9C4F  jne         100A9C61 
100A9C51  mov         ecx,dword ptr [ebp+0C8h] 
100A9C57  mov         edx,dword ptr [ecx] 

EAX = 00000001 EBX = 00000120 ECX = 00000000 EDX = 09440178 ESI = 08F1FA3C EDI = 08F1F9F4 EIP = 100A9C57 ESP = 08F1F9D0 EBP = 09487DC0 EFL = 00010246

Development News / Sending views to other monitors?
July 07, 2011, 09:06:10 am
I am trying to use the new feature of sending a view to another monitor. I think this is probably the menu command "Views->Open Additional Window", but it is always disabled for me. Can someone point me in the right direction, or is this a bug? Thanks.

I was testing out 2.3 standard beta 1 and experienced a crash. I wasn't doing anything in particular, just changing views and looking at stuff. As a programmer myself I appreciate how useless my report is to you given how little information there is but that is actually the point of my post - I would like to suggest adding an exception handling mechanism that emails you the call stack and registers when a crash occurs. I have found this to be extremely helpful in dealing with application errors experienced by customers and well worth the effort it takes to implement it. Depending on the situation you could possibly even save a user's work prior to exiting, giving them a chance to recover data (although it could be corrupt) but that could perhaps also provide you with the data you need to reproduce a crash.

Glad to see you are actively working on World Machine again!