• Welcome to World Machine Community. Please login or sign up.
September 22, 2019, 11:27:34 am


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.

Messages - Eric Cosky

Development News / Re: Feature Requests
July 23, 2011, 04:23:35 pm
In the layout view where there are many shapes, selecting all shapes and selecting "use bezier path" only converts the one you click on. I have dozens of shapes, and it would be nice if this command applied to all selected shapes the same way as the rest of the commands in the context menu.
Development News / Re: Feature Requests
July 20, 2011, 11:25:47 am
Speaking of GPU support, it would be really nice to be able to provide our own HLSL shader for rendering the world view using the standard (or some subset of) SAS annotations.
Development News / Re: Feature Requests
July 18, 2011, 11:12:27 pm
For what it's worth, I've spent a few days now dealing with how to get good meshes with the data coming out of here and I'm expecting to use a feature built in to Softimage to deal with generating LODs from displaced grids. I suspect this will give the best results. The Softimage decimation algorithm is pretty heavy duty with many useful control features. Aside from the fact it would take a lot of work to make WB create LODs as well, the main issue for me is that I've come to realize the need to edit the meshes in the 3d editor so that the LODs can take into account any changes of the highest level LOD. For instance, by adding a building to the world I may need to cut out some ground which the LODs will have to be manually modified to deal with if they had been generated upstream (in the pipeline, so to speak) by WB. If I did it in Softimage, I'd be able to just have the LODs created based on my modified version. Because of this, I'm not expecting to pursue getting meshes out of WB any more. Heightfields and related 2D data are what this app does really well and is what I'm going to focus on getting WB to create for me.

Regarding the GPU support, I can see doing a lot with a device that allowed me to edit HLSL code with up to 8 texture inputs/outputs and access to a set of global float/ints/vector2 that people could use as control inputs. It would take some work on your end to provide the hookups, set up the rendering and pull the data back out of the render targets, but it would be an amazing feature to have access to and it seems like something a device could do internally without changing the entire app's architecture.
I figured it out, sort of. It is in fact reducing - I misinterpreted the results. I had put in 256, thinking that "Target kTri count" meant "target triangle count". When the file had hundreds of thousands of triangles I assumed it wasn't working because I expected a small file with around 256 triangles.  It turns it "Target kTri count" seems likely to mean something like "Mesh reduction factor" as opposed to "how many triangles are we trying to produce". Or maybe it's edge subdivision? The help page for the mesh output doesn't even mention the reduction feature (incidentally it also doesn't mention the mesh output device's mask input, and I have no idea what it is used for).

So, can you perhaps explain what this target count really controls, how the reduction algorithm works in general terms, as well as what the mesh output device mask input is intended to be used for?

Thanks for any info
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-
Awesome, glad to hear it!
Definitely strange; perhaps I'm just doing something wrong but it seems pretty straightforward.. I've tried a couple times since this morning and haven't yet seen any triangle reduction occur. I'll take another look at it sometime soon.

Also, the peak memory usage appears to always often be the same as the current memory used.
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.

Attached is a simpler version of the scene. The crash is apparently related to the erosion device. Crashes when tile render is triggered.
Thanks for any fixes!
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

Ok it was the lack of pro mode disabling it. Based on your renewed (at least now-visible) efforts on improving this tool I decided to upgrade to pro and I see the other monitor display works fine now. It would be nice for the standard users to not see that menu item, it only confused me to see it greyed out all the time.

Sorry I wish I could provide more information, but I was quickly bouncing around the various views looking to see what was new. If I get any more crashes I will pop it up in the debugger and post the call stack and hopefully the scene that did it. To be honest, having only recently renewing my interest in this app after quite some time away, I wasn't really sure how active you guys are on the development. I'm glad to see you're on top of it and will do what I can to track & provide more information as problems occur. I am hoping to use this as a core content generation tool for a project I am just now starting so I am happy to do what I can to help.
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!

Nice to see activity here, looking forward to more.

I see on http://www.world-machine.com/download.php the link to "Comparison Page" points to chart.htm, and not the comparison page linked to at the top.