realtime viewports
23-Feb-94 03:55:54
Sb: realtime viewports
Fm: Don Hanson 71344,2201
To: Jonas Ruikis [ADESK] 73172,1351
Concerning dialog controls which can affect realtime viewports:
Sliders are built in, buttons just require custom feel_functions, but
editable fields (int/lint/float/lfloat) require mucho work rewriting
the edit_feel function? Would this edit_feel function would have to
be changed by the Yost Group?
If so, I would ask that this be done. One of the many cool things
about the SDK3 is the interactiveness which it allows, I think
removing this ability from some of the controls severely hampers
this. Please put me down for a suggestion to add the ability to
update a viewport to editable fields. Ideally, the programmer would
add this ability in a manner similar to the ClientSliderAction method
of easiness, although you know we'd be happy w/ just about anything.
(No-'cause it would be WAY too much work IS a very acceptable
answer) 🙂
Reading my new trusty manual I see Exp_Select_Input_Obj and am very
happy. Now I must ask the other side of the coin: after reading in
the selected object's vert/face info,etc., can the object be written
back out to? (put_vlist, and such?) This would allow AXPs which
work on all objects encompassed by the bounding box, instead of
tagging each and every object. That would truely be awesome.
Suggestion: Give AXPs access to the Exp_Extents command/info.
New Crusade: The animation start/end frame and render-by-N-frame
information can be very important to routines which run at render
time. You can write the current field to a state file/variable and
then compare each frame to get the render-by-N-frame value. But AXPs
are not given access to the start/end frame info like SXPs are.
Please put me down for a suggestion that this be changed.
Light question of the day: Since 3DE.exe will not be included in the
release version, does this mean there will an expanded section on
manually building your own Dialog monster union statement?
liking this new forum, Don