[AutoIT]Possible 3d display UDF

[tirpider]

A Simple 3D UDF (plugin) for AutoIT showed up on their forum today. It looks promising as a method for previewing meshes in SchMEe.

Simple 3D Graphics with GDI+ (link to AutoIT forum post.)

It does not appear to support textures.
But it looks like it draws lines from point to point quite well and has camera rotation functions.
That should be perfect for showing wireframe previews of models and identifying UV islands, clusters, and triangle strips.

What makes this stand out is the easy to implement examples and the fact that it does not rely on OpenGL or DirectX (meaning no DLL's, yay!)

It looks like he just did the hard thing and used GDI+ calls that are already in windows to force the 3d math onto the 2d functions.  Certainly not efficient, but right in line with how SchMEe works. Hacks and kludges, all the way down .

I added some very lowres screens of the examples to this post.  The last 3 rotate.

I already have some code that draws based on the STRP (triangle strips) so it shouldn't take much to adapt that to this library. I'll post a screens or notes about this here, but will keep development on it seperate from the main program so I don't break anything.

-edit
Looking at the code now. It looks like I will have to rewrite some of it to fit the encapsulation scheme I'm trying to conform to.

All of it's globals are fine, but some of the rotation functions take matrixes as paramaters. I'll probably switch those to an array.

I think working this into shape will help start the process of cleaning up my own code.
Still hung up on the interface, but If this renders fast enough, then it would be tempting to build a GUI around a mesh preview. It would certainly be pretty.

[SleepKiller]

It would certainly be pretty.

Wire frame renders of models are pretty?

I'm kidding, this sounds great for the program. It would certainly be great to have a visual representation of what the model is looking like.

[Phobos]

This sounds really cool and I would like having wireframe view support for Schmee. I don't like using those other obscure apps to generate a wireframe TGA.

[tirpider]

I'm glad ya'll like the idea.

I dig 3D Object Converter, but having to use it to find segm's and view pieces is a real hassle.
You would think XSI would be better at that, but it really isn't because it is so big. Clusters are buried deep in it's scene explorer.

This one may take a couple (maybe a few more than that) of days to test out.
I expect it to work right out of the box, but making the window for it will take a couple of tries.
The first results will just be a plain popup window with a wireframe.
Then I'll work on making a menu of some sort for it.

I'm already (mentally) sorting out filters for viewing collision primitives, shadows, and hardpoints.
And drawing a wireframe of cloth would be easy....
Proof of concept first though.

[tirpider]

Double post to isolate the thoughts.

Welp, it's drawing the mesh just fine, but I am having trouble sorting out the camera angles/rotations/things...

In the attached image, you will see the wireframe of the first SEGM (cluster) in all_inf_trooper.msh, which is his body and hat, but no backpack, face, or shadow.
The camera is looking at the origin (0,0,0) directly between his feet.
The camera's location, however, is acting wierd.

Here is how the camera is set up: (based on the examples)

Code Select Expand

Local $position_x = $Model_Width / 2
Local $position_y = $Model_Height / 2
Local $position_z = $Model_depth * 2
Local $target_x   = 0
Local $target_y   = 0
Local $target_z   = 0

_S3d_SetCamera( $position_x, $position_y, $position_z, $target_x, $target_y, $target_z )


I was expecting the camera to be located at the center of mass for the model (half x and half y) and was just guessing for z.

But the camera is somewhere under and behind the model.
The position parameters seem to rotate the camera. And not in the expected ways.
Hard coding the values instead of using the width and such doesn't help.

So, I'll need to spend some time inside the _S3d_SetCamera() code to figure out how it's doing what it is doing.
(I guess I could ask the guy directly.)

So.. half success so far.
It's drawing it (yay!)
But it is being obtuse about letting us see it. (boo!)

If any of ya'll want to take a swing at it, I can post source.
It's got everything except _load_msh() disabled in this build, so it's just:
Load MSH > Draw first SEGM > esc to exit.

Work continues....

-edit
Ok, the 2nd attached pic shows some progress.

- The lines are thinner. The thickness is just from the examples these tests are based on, not the UDF it'self

- Camera is under control. Sorta.

I asked the dev what axis he was using and they are different. Not uncommon across 3d applications. He also explained that to get the camera to move where I want, I have to adjust both position and target.  I should have known that, but didn't. So it looked like I was rotating wildly by using incorrect measures of width/height/depth across incorect axis and not changing the target view of the camera.  (Just typing that makes my eyes cross.)

Anyway, here is the translation of axis for S3D and MSH:

Code Select Expand

S3D              MSH
y = left right = x
z = up down    = y
x = fore aft   = z

I compensate for it by simply changing the name of the variables I'm loading the POSL data into.
And the revision of the camera line from above:

Code Select Expand

Local $position_y = 0                  ; horizontile center
Local $position_z = $Model_Height / 2  ; verticle center of model
Local $position_x = 2                  ; need a way to calculate field of view
                                       ; to determine how far back to put the camera
Local $target_y = 0
Local $target_z = $Model_Height / 2
Local $target_x = 0

_S3d_SetCamera( $position_x, $position_y, $position_z, $target_x, $target_y, $target_z )
It will be polished more before making it to SchMEe.


I can't express how exciting this little thing is for me. Did not expect to see something like this pop up over there. I was dreading having to wrestle the GDI stuff myself, and oh god, the matrix stuff.

It isn't without it's bugs:
Alt-Tabbing causes the form to erase itself. It will need to detect when the program looses focus and redraw itself when needed. Of all the issues, this is the most awkward.

I'm not sure if there will be any live rotate abilities, since it's basically just a 2d projection. I may make commands to change to various perspectives (top, left, back, front, ect..) or just do the top/side/front all at once.  It is meant as a preview, so it doesn't need to be terribly detailed.

And it is much slower than his examples. That's ok though. This particular cluster has around 1000 vertices and 1300 or so triangles, compared to the 8 point cubes he was drawing, I expected it to be slow.  It is kinda cool watching it build the triangles though.  (coincidentally, it's drawing on a surface that can just be "saved" as a bmp like the uv stamps. kinda useless, but fun.)

It's enough for me to not fear designing a GUI around it.  I think I'll move all the options and commands to menus (like the MSH_INFO program.)  A basic treeview on the side to pick models or clusters, and a data display area that knows what view to show based on what is selected.  Need a way to make all that modular so adding views or options isn't such a hassle.

This one is going to be a good amount of work, and I'm seeing the need to re build the program flow before building it in. So it probably wont be in the next few updates.

I could make a little viewer-only app though. That will give me a platform for testing code like auto sizing the drawing area, and auto centering and positioning the view. cool. I think that's the plan.  I can see where the wife is going to hate it. (It's going to eat time.)

[tirpider]

Triple post to isolate the thoughts.
(this may get split off at this point, or not. I'll be refering to and editing this particular post a bit as it moves forward.)

MSH_WIRE (viewer only)
notes:
- going to explore using this as a visualizer for schmee.
- this will give me an opportunity to harden some aspects of the schmee code.
- if the two do merge, it will be schmee's code that gets adapted to this instead of the other way around because of the flow improvements this program will have.
- right now, it's just all the dependent functions and globals needed to load a msh without an error.


Basic flow: (purposely over-simplified)
- read commandline
- if no file indicated, show blank drawing area.
   - offer to open a file or have a menu option for it.
   - (optional: drag and drop?)
- load file (msh)
- draw wireframe
- (optional: change/rotate view)
- (optional: select/highlight discrete geometries)
- esc or [X] to quit

Tasks: (vaguely prioretized)
- [revise code] Consolidate file loading as much as possible
- [revise code] Get a grip on all constants
- [revise code] Implement get/set for MSH data
- [revise code] Optionally optimize file load to reflect task (load only POSL and STRP(or NDXL/T as needed))
- [study] evaluate rotation in s3d to see if it can be used to rotate pieces in msh/SchMEe
- [add feature] basic GUI ("file" menu, wireframe graphics area, optional tree/list view)
- [study] Determine what sort of data is needed when looking at wires
- [add feature] GUI elements to provide data/feedback
- [add feature] preserve drawn sequence as an array for refreshing the display
                         (this should be faster than reading it from $aMSH_DATA every time)
- [add feature] optimize drawing sequence (sort by coordinates)
- [add feature] Draw cloth wires
- [add feature] select "pieces" (clusters, strips, and/or individual polygons)
- [add feature] rotate view
- [add feature] selectively display collision, shadows (both types,) cloth, and/or normal geometry
- [add feature] optional color coded clusters (SEGM)
- [add feature] optional color coded triangle strips (STRP groups)
- [add feature] optional display bone and hardpoints separately or as an overlay
- [add feature] optional capture/save image
- ?


(need to attach source here)
If you are studying the source, then the code for this program (aside from the s3d specific stuff) will contain only what is needed to load a msh. It may be easier to follow how it works than the giant SchMEe code.

I'm doing this to optimize the code a bit and to re-work how the MSH data is handled. I want it to act somewhat like objects, using get/set functions to retrieve data. Inside those get/set-ers, there will be validation code and triggers for other functions to make building editing functions cleaner and more consistent.

Adding the wireframe is a significant enough change that I really need to do it separately anyway, so this is a plus. I can still add functions to SchMEe, but also work on revising it here without breaking it completely.

Once this is integrated with the schmee code, I think I'll bump the version to 1.0 and open it to the board. I don't expect a lot of hooplah over it, but who knows?  It should be a lot easier to operate with some method of visualizing. (still focusing on commandline as the primary interface though.)

-edit
Been going in circles for days. Revising the load sequence, fully encapsulating the $MSHData arrays, and defining all the constants needed to manage them.. yeah.. that's a lot bigger task than I anticipated.

I could stay focused on it and maybe get somewhere with it in a few weeks, or I can drop it for now, and get back to the GUI. It will happen, but when it does, it will be part of a much larger overhaul than this one.

So I lined out the initial plans for all that. This is still the best way to see how the MSH is loaded, but it is kinda scattered.  It is still kinda isolated, so a person could comment out main and use this code as an include for loading a msh for other purposes. It has all the important core pieces needed and only essentials exposed to the programmer (the global msh containers, and only one function, _load_MSH(), I believe.) The rest are helper functions and constants, so if a person wanted to do whatever with a MSH, this source would make an excellent start without having to wrangle all the extra stuff in SchMEe. It's messy, but it gets the file in memory where you can do whatever with it by juggling the arrays....

I'm doing it again.

Back to the point.
The code revision is postponed till the next major revision because of the complexity. It isn't really hard, it's just got so many little pieces.

I'm back on the GUI. Then back to features on SchMEe proper. Then possible integration. (Or I may jump in and just put it in anyway.) But this GUI need to be done.