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 - sfriedberg

Pages: [1]
So far I've just messed around with filters whose inputs and outputs were the same size.  I'm now attempting to satisfy my own feature request for a general horizontal coordinate transform device.  To supply an output over a requested worldspace extent will require input data from very different worldspace extents.

As one specific example, let the device output a 45 degree rotation of its one input.  To fill an N x N output grid without gaps, it needs access to an 1.414N x 1.414N input grid.  As a second example, let the device output a M:1 compression along the X axis.  To fill an N x N output grid without gaps, it needs access to an N*M x N input grid.

I don't know how to do that, and now I realize there's a lot about the WM architecture I don't understand.  So the following questions may just be "wrong questions"...

Q1) I see a few references in the PDK to "proxy builds".  Is this where the desired render extent gets expanded into specific build extents for each device?  What's the sequence of events relative to proxy builds and Activate calls?

Q2) Can/Are BuildContexts be modified (or a new proxy build be triggered) on the basis of parameter change?  (Assuming: yes)

Q3) Ignoring output tiling for the moment, will a device ever get multiple "fragmentary" Activate calls on a single world build, to fill in various subregions of its output?  Or, can a device ever call RetrieveData multiple times on the same port to get different input packets on a single Activate call? (Assuming: no)

Q4) If a device needs input from a known non-square shape, can it call for multiple input packets that cover that shape more efficiently than the single enclosing square of input?  (Assuming: no)

Q5) If it's possible to achieve my objective, are there any code samples to look at?  Certainly none of the simple examples in the PDK do this.  I've looked at howardzzh's Downsizer example from 2007.  While that generates an output smaller than the input, there's nothing in that code that calls for any particular input (or output) size.

Tonight I was trying to stretch out an Advanced Perlin generator, and could not find a way to scale one axis differently from the other.  The two closest approaches were to hook a Gradient generator to the AP phase distortion input, and alternatively to hook both the AP and the Grad into a Simple Displacement.  However, both approaches are seriously limited by the maximum useful width of the gradient.  I'm looking for something that will apply to (infinite) textures as seen in the explorer view.

Also, the next objective after stretching a generator is to rotate the result to align the "long" axis with some specified input angle.  Setting an arbitrary axis of stretch would also be acceptable for random generators, although stretch-along-arbitrary-axis and rotate-after-fixed-axis-stretching do not give the same results for general input.

Unless I've overlooked something (quite possible!), the old never got recompiled and redistributed after the VS2010 changeover.

So, what I'm looking for is a general (horizontal) coordinate transform device that 1) accomodates effectively unbounded textures from generators in world or relative worldspace, 2) allows non-uniform scaling, and 3) allows arbitrary rotation (of either the principal scaling axis or of the result post-scaling), and 4) some reasonable attempt at proper interpolation/resampling.  It would be fine if the scaling factors were limited to <= 1, as that could be compensated in the source generator scaling.

If there's already a way to some or all of what I want, an education would be greatly appreciated.  WM 2.9 and 3.0(dev) on-hand.

Plugin Development Forum / Any plan to move off VS2010 Express?
« on: August 28, 2014, 04:42:04 PM »
Not promoting the idea, especially, but the 3.0 release train might be a good time to move off Visual Studio 2010 to whichever of 2013 or 2014 MS is promoting as its next "stable" development platform.

I'm considering a plugin (or family of related plugins) with a potentially large list of parameters.  The majority of these parameters should be set consistently across instances of the plugin (family), and ideally should be loadable/storable to a file.

Obviously, it's possible to go into each device instance and load the desired configuration.  I'm curious if there is a PDK-supported way to share this data across multiple device instances without the explicit loading step, either completely implicitly behind the scenes, or explicitly in layout by wiring each device to a "configuration master" device.  I'm looking for something more structured than simply stuffing data into a global variable.

Plugin Development Forum / ETA on 3.0 PDK?
« on: August 20, 2014, 06:01:48 PM »
I'm assuming the 2.9 PDK is not compatible with 3.0dev, or at least not complete w.r.t. the major new features.  When should we expect an initial 3.0 PDK?

First a bit of context.  I've been programming professionally in C since the late 1980's for Unix and Linux, but have negligible exposure to the Window development environment.  The last time I dabbled (correct word) with C on Windows was in the VC5 timeframe.

I've downloaded the VC2010 Express installer, installed it (96MB download), and updated it with the Windows Update security patches (266MB download).  [Rhetorical aside, how is it even POSSIBLE to have 266MB of security patches to a 96MB software product?!]

I loaded the PDK 2.3.5 example project "solution", left it in the Debug(Win32) configuration, and in the project properties added include directories "{blah}/src" and "{blah}/src/support", added library directory "{blah}/lib", told it not to use pre-compiled headers, and changed the library dependency reference from "corelib.dll" to "corelib32.dll".  I also told the project not to use the resource file, since the afxres.h it depends on isn't present.

This gets me through compiling the sources, but at the linking stage I have a couple of issues.  There's a warning about a conflict between /INCREMENTAL and /LTCG that I'm presently ignoring.  There's a hard error involving inconsistent values for _ITERATOR_DEBUG_LEVEL (0 versus 2) that I don't know how to deal with.

I'd appreciate any guidance, suggestions or handholding so I can actually build the PDK examples properly.

Feature Requests / Sedimentation device
« on: August 16, 2013, 08:35:28 PM »
I've been pondering a workflow that would do a geological simulation to generate a bunch of mask maps before launching into WM.  It would be handy to have a sedimentation device that could lay down ocean floor or volcanic ash layers.  Layer thickness controlled either by a mean thickness parameter or by a thickness guide map.

I want to fill in low areas without eroding the high areas, so the erosion devices aren't ideal for this.  I've got a macro that approximates the desired behavior by doing some arithmetic and a "max" on an input terrain heightfield and guide map, so this is a low priority.

Feature Requests / More control over the curves device
« on: July 26, 2013, 04:30:24 PM »
I wanted to linearly scale heightfields.  As a new WM user, I overlooked the scaling option of the clamp device and used the curves device instead.  Trying to draw a straight line to a particular value on unlabeled axes was no joy.  It would be great if curves added knots like the loft profile edit tool.  Curves has a disabled button labeled "cubic spline" (version which suggests this is on the way.  If it's already present, I couldn't figure out how to activate it.

And some rudimentary axis labeling (even just ten tick marks) would be a helpful addition.

I'm using layout generator curves to carve out broad valleys (and then the same curves again in a 2nd generator to carve river channels).  It would be nice to have a couple more editable options to help blend these shapes into the surrounding terrain.

1) Cross-sectional opacity profile.   Default would be the current overall opacity slider value uniformly across the profile.  Could be edited, for example, to have much less opacity at the edges of the profile, allowing better terrain blending without sacrificing any longitudinal loft profile accuracy at the center.

2) Longitudinal falloff profile.  Default would be the current overall falloff slider value uniformly along the curve.  Could be edited, for example, to have valleys with narrower ends, or other features of varying width.

Feature Requests / Height splitter with adjustable thresholds
« on: July 26, 2013, 04:12:35 PM »
I wanted to slice a height field into elevation zones, but the fixed band placement of the height splitter device wasn't right.  Using a bunch of height selectors, I got what I wanted, but I had to spend a bunch of time with a temporary setup of curves and combiners setting the threshold values and fuzziness/falloff so that the adjacent zones blended properly.  It would be nice to have a version of height splitter where the interband thresholds were adjustable and you got add-to-one overlap automatically.

Feature Requests / Faster cancellation of layout generator build
« on: July 26, 2013, 03:45:57 PM »
Using version, if I cancel a build while it's in the middle of a layout generator (which may take 5 minutes in the project I'm working on), I get the do-you-really-want-to-cancel dialog immediately, but as soon as that dialog is complete WM becomes unresponsive for a considerable time (minutes).  Apparently, WM continues working its way through the layout generator, until that stage of the build finishes, before actually cancelling the rest of the work

It would be nice if the layout generator (and other potentially long-running devices) checked for cancel/abort inside their processing loops.

Pages: [1]