Jump to content

C. Andrew Dunning

  • Posts

  • Joined

Posts posted by C. Andrew Dunning

  1. Jeff -

    You are quite welcome!

    I think you have discovered what many have come to accept: things ALWAYS take more time than anticipated. My wife translates "I'll be in my office for a few minutes tinkering with a script idea" to be "I'll see you in a week."

    Do you want to share a little about your project? I'm now pretty curious...

  2. Jeff -

    You are right: quite a can of worms. Once things are working, though, a very useful can.

    As to your question, do you have your vsoWidgetPopupClear and vsoWidgetPopuoAdd calls in a "41" event? Someone may correct me if I'm wrong, but I believe that doing that will do what you want.

    Regards -

  3. Here are some things that might help you. They are a collection of things that have been shared with me recently by individuals much wiser than myself, so I take very little credit for anything useful below...

    First, what you're wanting to do is quite doable.

    Second, you'll want to do a little reading. See Shape Pane Page and the calls under "Document List Handling" @ Main Developer Page . The first link includes a link to an example file that may prove to be quite helpful. (It was to me.)

    Third, some particulars:

    The following will clear the popup you want to populate:

    vsoWidgetPopupClear([Widget/Parameter Number]);

    The following will fill the popup w. the list of textures you have generated:

    [Resource List ID] := BuildResourceList(97,[Folder Index for Resources],[sub-Folder for Resources],[Number of Resources found]);

    If [Number of Resources found] <> 0 then


    For [Count] := 0 to [Number of Resources found] DO


    vsoWidgetPopupAdd([Widget/Parameter Number],GetNameFromResourceList([Resource List ID],[Count]+1), GetNameFromResourceList([Resource List ID],[Count]+1) );



    Re-read the first link, paying attention to the details.

    Let us know how things turn out.

  4. Jeff -

    A few comments that may or may not help:

    In working w. textures you'll need to be able to get a given texture's index (via Name2Index) and its handle (via GetObject).

    Working another way, you get the index of a texture applied to the PIO via GetTextureRef and then the name via Index2Name. Your test to see if a texture has been assigned is to check for an index value >0.

    As to setting the repeat, have a look @ SetTexMapBool. This is a VW09 or newer call that allows you to set horizontal or vertical repeat. You'll need the handle of the 3D object onto which you're mapping the texture and the ID of the part of that element being textured.

    Make sense? Enough to get you going again?

  5. I haven't tried a fly-over but changing views doesn't appear to be an issue.

    Controlling the size and number of the facets in the mesh is part of the challenge and will be a function of how coarse of a mesh my users will find to be acceptable. There is obviously a trade-off between speed/object count and rendering accuracy.

  6. Did you end up using mesh objects?

    Yup. Whereas VW would choke when tube counts approached 200, using this approach lets me get to over quadruple that. If simpler flat elements, I can get in to the thousands w/o issue.

  7. Is this going to be a new feature in VideoScreen 4?

    Who knows...? I'd hoped something along these lines would have been ready for v2 but a combination of geometry generation and texture mapping challenges have made my hopes take a lot longer to realize than I'd anticipated. The former has been working for a while but the latter has really made my head spin. Every time I got above about 200 or so objects VW just didn't want to play. Things are starting to look up, though...

  8. If any of you are interested, here's an update:

    If I:

    1) Create the set of arcs within a group...

    2) Convert the group to 3D polys (and, leave as a group)...

    3) Convert the group to a mesh...

    Things work.

    In trying to follow some of Pat's early advice the problem was that I was trying to create the arcs within a "BeginMesh" VectorScript call. Didn't work so well.

    I still have some mapping challenges, but at least I'm getting the texture to map in the first place.

    Thanks for the thoughts...

  9. Pat -

    This is an array that is a mesh. The array is created in a script following a "BeginMesh" call. Using this approach I'm able to map a single Texture across a large number of objects.

    FWIW, I had originally taken the approach of individually mapping the Texture to each element in an array - and adjusting the offset appropriately for each. That worked, but VW would choke when I got to a few hundred elements in the array - and I'm needing to be able to map to higher numbers than that.

    Is the advice you're offering in-essence doing this, or something different? The closest thing to what you mentioned (that I could find) is one of the settings for "SetTexMapBool." Is this what you're meaning?

  10. I've attached 2 files:

    FlatMesh is an example of the intent of what I'm trying to do - map a single Texture across the array of objects. That image used 3D Polys.

    ArcMesh is the array of the arcs onto which I'm trying to map the Texture. This is the one not working.

    FWIW, converting the extrusion to 3D Polys didn't seem to fix things.

  11. Greetings!

    I am trying to create a Mesh of an array of extruded arcs. My question: Is this even permissible? I can create the geometry just fine, but Textures applied to the Mesh seem only to be applying to one of the arcs (there are 48).

    Am I missing something?


  12. Assembly -

    A few questions:

    - Your signature notes 2 different versions of VW. Are you seeing this odd behaviour in both?

    - If you're only having the problem in `09, are you running the current update?

    - Are your child objects event-enabled?

    One of my PIOs uses a similar approach to create parent/child objects. Both the parent and the children are event-enabled. In one of the early releases of `09, I was having issues not unlike yours. NNA fixed a bug, but in the mean-time, turning off the event enabling fixed things @ my end.

    Not sure if that helps, but something to consider...

  13. Pat and Petri are correct; the articles on VectorLab are incredibly helpful. If you're like me, you may need to read them several times for things to click - but WELL worth the time.

    As to setting parameters, try a couple of things:

    - As part of the initial dialog set-up, read current PIO settings into the dialog using the PIO OIP field names (Pwidth, Pheight, etc.) and calls like "SetItem," "SetEditInteger," etc. to transfer those values into the dialog.

    - In the "OK" event, use "SetRField" to write the resulting constant values back to the PIO.

    That help at all?

  14. I'm not arguing this hypothetically. I know I'm right out of experience.

    And that's where the value of forums like this can be so great. I, too, know I'm right about the way that I work being THE way to work, but the more I can see other approaches and get other perspectives the better. I might see a way to improve my particular method - or I might see value in changing the way I do things.

    At a trade show this past fall I watched a VW demo. The person giving the presentation has a significantly different aproach than mine. The more I listened to him, the more wisdom I saw in his perspective. My workflow hasn't changed to match his, but I came away with a respect for his approach.

    Whereas we often had problems with rogue Classes on printed drawings, since switching to Viewports for production prints we've had none.

    I don't believe I've ever had issues w. rogue Classes. I have, though, learned the hard way about the ill effects of different Class visibility settings regarding VPs. For example, if a VP lives in a Class called "Bob," that class has to be visible in the VP when the VP is visible in order for the VP to update correctly.

  15. The user is keenly aware that to change the printed view they have to actually edit the Viewport itself.

    I agree w. that - and appreciate your needing to "manage" your users.

    At the same time, I often find myself doing a lot of Saved View updating. I used a 3rd-party script to do that before NNA added the functionality into VW. Now that it is native, doing that is incredibly easy. I would find managing Saved Views through VP settings to be much more cumbersome than necessary.

  16. It's far easier for mistakes to be made when it comes to printing if Saved Views are part of one's workflow.

    How so??? I'm not seeing the link here.

    For my workflow, both Saved Views and ViewPorts are absolutely essential to my VW productivity. One does not (and, I don't think, was ever intended to) replace the other. I use Saved Views to make managing ViewPorts easier - and occasionally use ViewPorts to create/update Saved Views.

  • Create New...