Jump to content

Cloud Hidden

Member
  • Posts

    333
  • Joined

  • Last visited

Posts posted by Cloud Hidden

  1. The 2D Rotate tool should have an option to duplicate the selected object, just like the mirror tool does, and also should have an option to do multiple duplicates. I space items around domes, and having to select, duplicate, get the start angle, set the placement angle, change tools, select the original all over again, etc is a pain when placing objects at irregular spacing around the dome.

    It'd be nice to select, set the start angle, and click, click, click to place 3 copies.

  2. Upon using the script further, it seems that RedrawAll does not cause the boundary recalc. What seems to make it redraw to match the 3D points is a solids operation, such as AddSolids (which I was adding coincidentally when I added the RedrawAll). Without the AddSolids, RedrawAll has no effect on the nurbs that I can see.

    I simplified the script to show the problem. Run this with any diameter, and with a height less than D/2 and look at a side view. It draws as a hemi, but the vertices show the proper height.

    Any ideas?

    code:

    Procedure Oblate;

    VAR

    pX, pY, pZ, cx, cy, cz : REAL;

    hNurbs : HANDLE;

    i, j :INTEGER;

    BEGIN

    DSelectAll;

    cz := DistDialog('Dome Diameter:','0') / 2.0;

    hnurbs := CreateHemisphere(cx, cy, 0.0, cx, cy, cz);

    cz := cz / 1.4;

    cz := DistDialog('New dome height:',Num2StrF(cz));

    hnurbs := ConverttoNurbs(hNurbs, false);

    Ungroup;

    hNurbs:=FSActLayer; {select the base of the dome}

    DelObject(hNurbs);

    hNurbs:=FSActLayer; {select the dome}

    i := 0;

    while i < NurbsGetNumPts(hNurbs, 1) do begin

    j := 0;

    while j < NurbsGetNumPts(hNurbs, 0) do begin

    NurbsGetPt3D (hNurbs, i, j, pX, pY, pZ);

    if pz<> 0.0 then NurbsSetPt3D (hNurbs, i, j, pX, pY, cz);

    j := j + 1;

    end;

    i := i + 1;

    end;

    RedrawAll;

    END;

    Run (Oblate);
    [/code]

  3. I don't suppose you'd make wall framing code "open source" so that we could expand upon it, would you? I just learned to my dismay that it doesn't seem to look at curved walls--darn--which really puts me in a pickle. Great feature...potentially a huge time saver....but misses some of the things that are critical to me. I've been able to script my way around a bunch of the curve-related limitations, but this one would be lots easier with a head start.

  4. >any idea where find more info about how they react to math and trigo?

    Sorry, no. I'm at the limits of my understanding of it. I usually just repeat the question here, on the VS mail list, and in email to NNA and hope that Andrew comes to my rescue yet again!

  5. I know how to set the precision of angle dimensions on a global basis (Units). But I have a doc with dozens of angle and linear dimensions and builder now wants just degrees instead of degrees/minutes. Is there a better way than clicking one at a time? The selection commands don't distinguish be/t angle and linear dimensions, so can't use that. And can't see where to change precision via scripting. Any ideas?

  6. I listed something that might be comparable in this thread... http://techboard.nemetschek.net/ubb/ultimatebb.php?ubb=get_topic;f=21;t=000216

    Andrew Bell provided me with an answer in the VS mailing list:

    Nurbs have an additional set of parameters not shown in the OI palette:

    the knot values. Explaining exactly how they work requires showing some

    reasonably complex mathematical expressions, so I'll just tell you the

    code you need:

    NurbsSetKnot(h1, 0, 3, 0.5);

    NurbsSetKnot(h1, 0, 4, 0.5);

    ###

    I don't know if that gives any insights, but it tells me that these are complex beasts whose complexity is never fully visible. So when you're trying to replicate something, you're doing it without seeing all the information used by the nurbs.

  7. OK, I grok that (and thanks for pointing to a definition that referenced a hither plane and yon plane...that tickled my funny bone!). But I'm still at a loss for the meaning of the specific number, and why it's a distance. What does 100' mean or what does 3' mean in this context, or are the specific values more arbitrary than I'm trying to make them be? With a camera, focal length is mm of lens to film, so I'm trying to make the specific viewdistance value make sense in that context. And speaking of which, that's how I look at the Perspective values, but they don't really correlate to typical wide angle/telephoto values, so I never quite know how to pick a value other than trial and error.

    Thanks Andrew.

  8. What's the viewDistance parameter in the Projection command do? I've figured out that small numbers make the objects smaller and large numbers make it bigger, while negative numbers turn it upside down. But I

    can't figure out how it related to the SetViewVector parameters or the physical concept of a

    camera. If I use 100' as a value, that's 100' from where and to where?

  9. I already do bury them--only have a few inches of thickness to play with, though, be/c we build w/ thin-shell technology. But even at 4', which is the max segmentation I can absorb, it's still at least 12 too many 2x's on each typical full wall.

    Classic Catch-22...If I don't do the wall framing the builder will hate me, and they'll hate me if I overestimate their materials by 25%, which is about the best I can get now with the Wall Framer.

    What's the best way to position this? Do I add it to the wish list and hope for the best in the future? Since it's more than just another feature--it's about making an existing feature match building practices--I'd really, really like it to carry some weight. How about this....I'll remove some of my dome-related wish-list items for this and a feature to be named later!? :) Seriously though, I have scripted my way around things like making walls rise to the dome, and really don't need them nearly as much as this. This one's a pretty big one, be/c it gives info that builders use for bidding.

    Thanks for looking at it.

  10. The function takes 3 3D points, called location, target, and up. My guess would be that "location" would be the location of the virtual camera and "target" would be where it is aimed. But I can't then figure out what the purpose of "up" is, nor how to set it's parameters. Seems like location and target would tell all the info needed. Where have I misunderstood?

  11. I'm trying to create a nurbs curve that's a half circle w/ 10'R. My base curve for comparison is drawn with a half arc and converted to nurbs. So I used code with parameters so that every vertex in the oip looks like the base curve.

    code:

    h1 := CreateNurbsCurve(-120, 0, 0, true, 2);

    AddVertex3D(h1, -120, 120, 0);

    AddVertex3D(h1, 0, 120, 0);

    AddVertex3D(h1, 120, 120, 0);

    AddVertex3D(h1, 120, 0, 0);

    NurbsSetWeight(h1, 0, 1, sin(Deg2Rad(45)));

    NurbsSetWeight(h1, 0, 3, sin(Deg2Rad(45)));
    [/code]

    Except the curves don't match visually, even though everything in the OIP looks the same.

    code:

    h1 := CreateNurbsCurve(-120, 0, 0, false, 2);

    AddVertex3D(h1, -120*sin(Deg2Rad(45)), 120*sin(Deg2Rad(45)), 0);

    AddVertex3D(h1, 0, 120, 0);

    AddVertex3D(h1, 120*sin(Deg2Rad(45)), 120*sin(Deg2Rad(45)), 0);

    AddVertex3D(h1, 120, 0, 0);
    [/code]

    So I changed the code to the second sample--with byCtrlPts false--and now the curve matches the base curve visually. My question is why the first code doesn't match the base curve, even though every vertex looks the same in the OIP?

  12. Thank you. That's the one.

    VS is making it a whooooooooooooole lot quicker for me to build some of the more complex dome shapes. Latest is an oblate spheroid on a stem wall with an inner shell. Several dozen steps along with some tricky mousing to reshape the nurbs, now reduced to a menu selection and a few dimensions in a dialog. Tr? cool! Thanks for your work on VS.

  13. If I use the OIP to change the Z value of individual vertices on a nurbs surface (it's a hemisphere I'm trying to flatten), the change is visible with each point I edit, and as I get through all the U's and V's, the object is flattened to the Z I want.

    If I script the same thing...a loop through the U's and an inner loop through the V's with NurbsSetPt3D...all the vertices change, but the object is still drawn to the original elevation. I use DrawNurbsObject and Reset BBox and Set3DInfo, but with no obvious effect. Only after I click the "show vertices" box and the "reverse normal" box/button in the OIP a coupla times does the surface redraw properly. Strange. So what function is being called by the Reverse Normal button that I'm missing with NurbsSetPt3D?

    Edit: One solution I just discovered is to use ConvertToNurbs to convert the modified surface to another, and that one is accurate. But I'm still curious what's happening and not happening.

    [ 09-15-2003, 02:48 AM: Message edited by: Cloud Hidden ]

  14. Are there any special considerations for a dtm when roads intersect, such as when a driveway comes off a main road? Are there any known issues with components or modifiers overlapping? I have a main road and a driveway and the dtm will process either one of them, but not both. Any ideas what might lead to that?

  15. Andrew, thanks for a coherent response. 0 or 1 doesn't matter as long as it's added to the documentation. While you're at it, any chance of getting SetWallPeaks to set the Z value? Here's what I'm doing. Creating a polyline from a wall. Extruding it to wall height. Intersecting it with a nurbs surface. Convert to mesh. AddWallPeak @ 16" offset. GetWallPeak to find the X and Y. Walk the mesh to get the two closest points and interpolate a Z. Without SetWallPeak, I have to build an array of the Z's. With a malfunctioning GetWallPeak I have to clear wall peaks. Then I increment the offset 16" more, and add the next wall peak.

    When all is done, I clear once more, and add each peak again using the Z value I stored.

    It works, and it'll save me literally hours of work, but it's not clean. Any improvements y'all can offer are welcome.

    If you know who handles the wall framer, this exercise pointed out a bit of a problem with that that would be great to have adjusted. I wrote it in the VW Architect area.

  16. quote:

    In all cases, the index range is not nearly as important as the documentation.

    That certainly answers the one question. Woulda been nice if they mentioned if the index was 0 or 1 for GetWallPeaks. That coulda prevented a lot of time-wasting.

    I'm a one-time C developer, and have 0 drilled into my brain, and in translating to Pascal, assumed 1, be/c that's what I've seen in sample code. Thanks for the explanation. (and I'll never get used to := for assignments!)

    Still looking for answers on GetWallPeaks. I'm guessing that most people only have one wall peak, and that was the test case. Unfortunately for me, I have lots.

×
×
  • Create New...