chriscalef

And also, what parameters do you set in makehuman before you export? Y up versus Z up? Bones with local = global rotation? Babe in the woods here.

Hmm, okay... any quick advice on how you do that? It _seems_ properly rotated to the naked eye, as in my second image, where you can see the skeleton with fingers etc. looking like they are in the right position relative to the mesh.

Is it an export to collada issue, or is the skeleton rotation something I have to do to the model in Blender itself before the export process begins?

So, this weekend I finally tackled the subject of importing a rigged makehuman model to T3D... and am ready to ask for help.

I made some very impressive nightmare demon monsters though!

http://opensimearth.com/images/screenshots/blender_dae_t3d_04.jpg

My problem boils down to the skeleton coming in on the wrong axis (I think). Be default it ends up rotated 90 degrees around the X, ie face down on the XY plane. The stretched out mesh is a problem I've seen many times before, signifying a cumulative error in node positioning, ie adding the error of the parent to each child and so on.

Here's the working figure in blender, with the "game" skeleton rig from makehuman:

http://opensimearth.com/images/screenshots/blender_dae_t3d_01.jpg

But, backing up a bit: I first tried just saving collada files directly from makehuman. For some reason, this resulted in an invisible mesh, and I never did figure out exactly what was wrong with it, but it seems there are no materials at all. In any event, the bones seem to end up behaving the same as the ones from blender, so...

I soon moved on to exporting from makehuman to blender, using first mxh2 format and then just collada. From blender, I export to collada and import the results into T3D. In a model with no bones, this works more or less perfectly, in terms of mesh, textures, UV maps etc.

Here's an unrigged model, with the same pose but some clothes thrown in. It has some weird lighting issues (flickery lighting, and the fact that the clothes don't cast shadows, only the skin mesh does) but other than that he looks reasonably okay.

http://opensimearth.com/images/screenshots/blender_dae_t3d_07.jpg

However, with a skeleton, the default pose pictured above in blender ends up like this after import:

http://opensimearth.com/images/screenshots/blender_dae_t3d_02.jpg

In the shape editor, you can see the skeleton orientation. I played around with the override_upaxis option, and that did rotate my skeleton but didn't solve the main cumulative (read: demonic monster from the depths of hell) problem. Note that in addition to the overall rotation of the skeleton, there are also major issues with the pose itself, especially the arms.

http://opensimearth.com/images/screenshots/blender_dae_t3d_03.jpg

Here is a basic TPose, in the mission:

http://opensimearth.com/images/screenshots/blender_dae_t3d_05.jpg

And here's the same pose in the shape editor:

http://opensimearth.com/images/screenshots/blender_dae_t3d_06.jpg

I'm remembering some sketchy methodologies in the collada importer when it came to fixing up axis / handedness, and am afraid it's going to come down to a full-on engine problem here, but before I go there I'd love to know if there's just some setting I missed somewhere.

Anybody doing this every day and willing to share their system?

Ah, awesome, thanks!!!

Ping... @Timmy, got any recall on this one?

Hm, yeah that didn't seem to work for me, I tried that first. But now that that particular issue seems to be out of the way, is there anything weird about how we're looking for OpenGL that might be biting me?

Okay, the permissions problem is solved, for anyone who runs across this issue with a windows drive on an ubuntu system, my solution involved adding the following line to my /etc/fstab file and making sure contradictory information was not being called in my /etc/mtab file. (You will have to ensure the correct drive names, etc for your system of course.)

/dev/sdb1      /mnt/sdb1      ntfs     default,uid=1000,gid=1000,dmask=027,permissions     0      0

I'm not an expert, so use at your own risk.

But anyway, my new problem has to do with that libSDL issue mentioned before. Namely, it can't seem to use the symlink, because I have symlinks automatically set up by the build system which point from libSDL2-2.0.so to another symlink called libSDL2-2.0.so.0, and thence to libSDL2-2.0.so.0.4.0 which is the actual 6 gig file.

I've tried making these hard links, and then simply copying the actual file to both of the above names, making sure all are executable, but it continues to report "cannot open shared object file: No such file or directory"

Any ideas? Has anybody else compiled 3.9 on ubuntu yet?

EDIT: answering my own questions here, maybe this would have been done for me had I gone the "make install" route rather than copying files manually, but I got past the libSDL problem by copying libSDL2-2.0.so.0.4.0 into my /lib directory under the name libSDL2-2.0.so.0.

So, with that obstacle breached, my next one appears... I get actual console output, starting with "Initializing platform...", and things seem to be going pretty well until it gets to the renderer, where it first tries D3D9, then goes to OpenGL, and can't find OpenGL for some reason. It then tries the Null Device Renderer, makes it for a few more lines and then seg faults.

I know I have OpenGL installed, other 3D apps work and I have freeglut3 and freeglut3-dev up to date.

Hmmm.

I know I've been here before, but long story short: how I got here was, because of temporary lack of the Project Manager, trying to manually add the physx3 code and include + lib directories to my new 3.9 build, using VS2015. My solution last time I saw this problem was terrible (actually changing the name of Torque's StringTable, everywhere it appeared :-P ) but I think the right answer just boiled down to switching the order of some includes, or something equivalent.

My error output is this:

1>f:\physx-3.3.1\include\physxvisualdebuggersdk/PvdObjectModelMetaData.h(227): error C2059: syntax error: ')'
1>f:\physx-3.3.1\include\physxvisualdebuggersdk/PvdObjectModelMetaData.h(228): error C2143: syntax error: missing ';' before '{'
1>f:\physx-3.3.1\include\physxvisualdebuggersdk/PvdObjectModelMetaData.h(228): error C2447: '{': missing function header (old-style formal list?)
1>f:\physx-3.3.1\include\physxvisualdebuggersdk/PvdObjectModelMetaData.h(331): error C2059: syntax error: ')'
1>f:\physx-3.3.1\include\physxvisualdebuggersdk/PvdObjectModelMetaData.h(331): error C2238: unexpected token(s) preceding ';'

But when you go to that file, you see that it breaks on the following code:

	class StringTable
{
protected:
	virtual ~StringTable(){}
public:
	...
	}

When I added the physx3 code, I also added the include and lib directories to the end of their respective lists in the project properties, and that was all I did. I wonder if I could add them earlier in the lists or something? Or is it a matter of where to call the actual physx include files?

Not a silly question. In your PlayerData datablock (check art/datablocks/player.cs) for the following lines:

   minLookAngle = "-1.4";
  maxLookAngle = "0.9";   

The min angle is how far up you can look, max angle is how far down, in radians (pi/2 equals ninety degrees). So if you change maxLookAngle to 1.4 you'll look down as far as you can look up.

The next thing you may or may not be concerned about, depending on your application, is rendering the player's body, since now that you're looking straight down you might expect to see your feet. That means setting your renderFirstPerson value to true, but be warned, if you go this route you have probably bitten off some new work for yourself, depending on how your player model and eye camera positions are set up.

You can mess with these values in realtime using the datablock editor, too.

Sorry, been busy AFK but for anyone interested, I think the issue I'm having is related to Ubuntu's treatment of FAT32 filesystems. Apparently I have to install some libraries or something. The way I got here was throwing an old windows spin drive with a lot of room on it into my Ubuntu system. Will let ya know when I get it sorted.

Q. Does your current large world implementation work in multiplayer?

To the best of my knowledge, yeah. It's just a paging system for terrain grids, so as long as both clients have the same terrains they should be able to interact normally.

Hm, it seems like I have some kind of permissions problem on this whole hard drive, it's not my main system drive but rather a mounted spin drive under media/user/... Not sure what's up, there's obviously write permission because CMake and GCC had no problem making files, but I can't seem to set execute permission or grant group or public permissions. Argh. But, doesn't seem to be a Torque problem anyway. I'll see what I can figure out.

Am attempting to build 3.9 in Ubuntu 14.04, the only real hiccup I had was the CMake version but I installed a PPA for that and seemed to be on my way. However, on completion I had what appeared to be a very large executable file (182 M). Figuring that was weird but could be normal if we're including static libraries instead of dlls or something, I of course tried to run it, but got a "command not found" result. Also noticed that no matter how hard I chmod it, I can't give it any permissions.

Does this sound like I have a corrupt executable file? Would be interested in hearing at least the size of anybody's working executable (I didn't change anything in CMake except to set the project name, so I guess this is probably a debug build, will have to look that up.)

The only clue I saw that anything might be wrong was a failed link to libSDL.so, but I think that was in the build install phase, and the .so appears to be in my game directory. Hmm.

Any advice and/or hand holding would be welcome.

Also, I suppose I'd have to cook up an XML based storage system for forest, street, and item data, to replace sqlite.

Sure, if there's interest I'd love to help facilitate that! Would look forward to a good round of code review on my current implementation. In particular, threading of terrain loads would be a *massive* improvement.

Well, hey, I guess I've been under the same rock! Good news, WTG Sickhead!

Well, okay, since we're a small enough community that my vote literally counts (never experienced THAT sensation before) I feel obligated to inform the group that I have changed my mind after I voted. I went for the "aw, leave it alone, I don't want to change all my filenames and references when there's not a C# file within miles of my project" option, but if people feel it _must_ be changed then I'll align my vote with Andrew's options, .tsc & .tso.

Sounds like a great idea. I've noticed this problem as well, it's especially terrible if you're flying close to the ground. A constant circle of inward facing billboards creates _not_ the most realistic impression.

Glad to see someone else interested in this idea! I've done a fair amount of work in this direction, but haven't had time to finish it yet:

http://forums.torque3d.org/viewtopic.php?f=17&t=400

Is anyone still using Awesomium? I'd love to know about it if a version is being maintained!

Also, if you've already downloaded it, you might want to grab it again or fetch/merge if you're using the repo, I just put up an update.

Two changes:

1) removed the restriction that parent containers must be defined in the database before any of their children.

2) fixed a bug with clearResultSet, which should help prevent crashes.

Also, I found a little hiccup in my logic, in that you can't use vertical/horizontal padding as a way to move a container around on the form, since it is being used for its original intended purpose of providing padding between the controls inside it. This can be worked around by using two containers, the inside one defining padding between controls and the outside one providing fine tuned positioning, if you really need both functions.

Yeah, I don't mean to bag on the GUI editor, to be honest it has a lot more to do with personal preference than anything wrong with the editor. I just like typing I guess. :-)

@MilkywayM16:

Sure, no problem! And your questions are not at all stupid, thanks for asking them!

Would you mind explaining some of the bad things about Torque's GUI, why this one is better, why you use sql, how xml is utilized, etc?

The primary feature I added here that Torque was lacking is the ability to anchor controls to other controls, instead of positioning each control independently. I think this is a fairly common feature of more evolved GUI systems, but Torque doesn't really have a way to do it. What I mean is, in the big form in my screenshot, each of the dropdown menus is linked to the label to its left. If I move the label, it moves the dropdown. Furthermore, I can link an entire column of labels to one label, for example the one on top, and then if I decide the whole list is a little too close to the edge, I can just move the top label, and then not only it but its associated dropdown menu, *and* the entire column of labels below it, *and* all of their associated dropdowns, will be moved with this one change.

As mentioned in the other thread, you can achieve some of this functionality by using GuiContainers, but not at the control-by-control level of granularity I was looking for.

I realized how much I wanted this after spending countless hours on a wall-of-buttons GUI system for a certain long term project, and being frustrated many, many times by the fact that I forgot to put something in that really belonged near the top, and that meant I was going to have to move potentially dozens of other controls just to fit it in. I've never been comfortable using the GUI editor in Torque because of the way it scrambles my files, and the way dragging controls around with the mouse always results in almost but not quite perfect positioning, so what this has meant for me is hours of digging through the script files, changing x and y positions for each control manually.

Needless to say, my new system here beats *that* process hands down. :lol:

Re: SQL and XML - XML got added just to be friendlier to the folks who aren't comfortable with using SQL in their projects yet, but the reason I'm using SQL is twofold:

1) I discovered years ago that any game or application I start writing is going to have a lot of data in it, and in Torque natively this data tends to get distributed across many script files. When I needed more data that didn't properly go into Torque Datablocks or the mission file or any other predefined location, I found myself making up little comma separated text file formats and such, until I finally gave up and rewrote everything to use sqlite. From that day, everything has been awesome and I've never looked back! :D Mainly because now I know I only have to drag ONE file around with me, the database file, and every single piece of information that is not code or art is going to be in that file, accessible via a standardized and efficient querying process.

2) The other big reason, although I hate to admit it here, is because I also discovered long ago that it would be a very wise thing, at every available opportunity, to reduce my dependence on any one engine. Right now I'm looking at one of my projects (openSimEarth) as having its first client in Torque, but hoping to expand it into other engines as time allows. This GUI system, and everything else I've done to move data out of the scripts and into my DB, is a major step toward engine independence and interoperability.

For people who don't want to use SQL, though, as I said above, you can save a GUI out into XML, and then hand edit that XML file to add controls or change anchors, etc., and then using my tool here you can convert that XML into a Torque GUI with everything in its proper position.

It would of course be extra sweet if I would have written all of this into the Torque GUI editor, so that anchors would be tracked there instead of only in my standalone script, but see point (2) to understand why I probably won't be doing that right now.

Hope that answers your questions!

Just a head's up: I don't have any statistics enabled on my download links, so I have no idea if anyone has actually downloaded this or is at all interested. If you are, don't be a lurker, speak up!

Otherwise I might not get around to keeping the branch up to date...

Well, hello again!

Believe it or not, I actually listened to you people for once, :-) and due to an unexpected bit of free time at just the right moment, decided to double down and chase this thing to its natural conclusion. (Or at least a big step closer.)

For those who don't know what I'm talking about, you might want to take a minute to go read my first post on the subject.

So, the last couple weeks resulted in the following improvements:

- XML: There is now support for saving/loading XML files.

- The GUI for making GUIs is now fully functional. (And I must admit, was a lot of fun to write, once I got it to the point where I was using it to create itself.)

- Everything has been pushed to a new uiForms branch on my Torque3D repo on github (github.com/ChrisCalef/Torque3D)

- I also released a zip file version with an executable, so people can just download and use it immediately.

So, without further ado, here's the new look:

http://opensimearth.com/files/uiForms_1_0.jpg

Before I go further, however, I must make a small confession - the system is not entirely independent of SQL, which is one reason I included the compiled version, to support those who simply refuse to compile sqlite into their projects. ;-) The GUIs you see above only work in conjunction with the (included) database, called uiForms.db. However, what those two XML buttons do is A) save a form from its SQL form out into an XML file, and then B) convert that XML file into a .gui file for Torque.

What it does *not* do, yet, is allow you to make changes to the XML file and then import those changes back into the database, although that is a fairly small additional step and it may happen before long, especially if anybody whines about how much they want it.

So, if you don't want to use SQL, you can just keep my little Empty template build sitting around, and design your GUIs in it, and then kick them out into XML or just save them as .gui files, and use them in your final project.

The only advantage to using XML at all at that point, of course, is if you want to hand edit them, or make new XML files using the same protocol... but that might apply to some people here, so there you go.

BASIC USAGE:

First, to put it in your own project, you only need one script file (uiForms.cs), plus a couple of trivial changes to include and execute it, plus the handful of code files to support SQLite. You can grab everything you need by cherry-picking three commits from my branch on github, if you want to go this route.

But for now let's assume you're just using my executable. Fire up uiForms.exe, go to the Empty Room, hit F11 for the World Editor, and look for the uiForms menu up top. Click on the only option, and you should have the big form in front of you.

Now, to make a new gui, simply hit the "+" button next to the Forms list at the very top.

The only things you need to know here are that your form needs a Name, which must be unique for forms in your database, and it needs a Type, which must be a valid Torque standalone GUI window class. You can also set width and height here, or take the defaults and change them later.

Once you hit the Add Form button, it will create and select your new GUI in the big form. Note: the form itself is treated exactly the same as any other GUI element, except that you have to use the Form "-" button to delete it, and please do not attempt to parent or anchor it to any of its children, for obvious reasons.

Anyway, now that your new GUI has a name, you need to add some elements before it will show up, and you need to give it a position. The position (pos x, pos y) is defined for forms in terms of {0.0,1.0} to define a percentage of screen space, ie 0.5,0.5 puts the upper left corner in the exact center of the screen, regardless of resolution.

To add elements, simply hit the "+" button beside the Elements list, and fill in the name, type, and size parameters there. For Elements, the name must be unique within this form, but not for the entire database. The type has to be a valid Torque GUI control, or you will be sorry. I put in a check to make sure it's a valid class, but you're on your own to make sure it's a GUI class.

The Parent list is for containers, please do not get it confused with the Anchor lists! If you make a container control, then you use it as the parent for all controls that are meant to go inside it. Otherwise, the parent should be the main form for everything.

The Anchors are how you arrange controls next to one another. The left align / right align / etc. checkboxes tell it to line up the e.g. left sides together, instead of the default behavior of making the left side of this control line up with the right side of the control you are anchoring it to. IE, use "left align" checked, and top align unchecked, to make a vertical column of controls, but use top align checked and left align unchecked to make a horizontal row of controls.

WARNING: Do NOT make circular loops of anchors! The system will spin its wheels for a while and then give up, or potentially crash, but in no case will you get desirable results! And this is easier to do than you might expect, so please be careful.

Horiz Align and Vert Align are not supported yet, sorry. They were meant to give forms and containers the option of centering, left aligning, right aligning, etc. but I haven't gotten to this yet. If you want to center things, currently you just have to do the math and add an appropriate amount of horizontal or vertical padding to the appropriate elements.

Which brings me to the next subject I should explain a bit: each container has edge padding and regular padding, for both horizontal and vertical axes. As you might expect, the edge padding is what pushes all controls away from the edges, and the regular padding is what goes between controls.

Beyond the container padding, fine adjustments can be done with horiz padding and vert padding on single controls. These get added to the control itself when it is being positioned, but they do *not* get added to the next control in line, just so you know. (That is, if I want my "name" label to be a few pixels over, I can add a few points to its horiz padding, but that won't also add extra pixels to the text edit field coming after it - this would generally be undesirable.)

Outside of that, I think everything there should be self explanatory. My apologies for all the potential GUI fields I've left out here, I'm sure I'll run into more things and be forced to add them as I go. Already it's made my life MUCH better, however. :D

Oh, also, someone mentioned hooking this up to the GUI editor... I'm not sure how that would work, except that there is certainly nothing stopping you from taking the gui output from this system and working on it in the GUI editor. It won't go the other way, however.

Oh yeah, almost forgot the most important part - WHERE are the gui & xml files? Fortunately, they're very easy to find, they just get dropped right into the main game directory. Feel free to modify the script to put them wherever you want, it happens at the very end of the makeSqlGuiForm / makeXmlGuiForm functions.

Which brings me to one more important part: you can just use the makeXmlGuiForm function on its own, in your own project, without sqlite, to convert your XML files to GUI files, and skip my whole little interactive form here, if you just REALLY love typing instead of pushing buttons.

And with that, I think I've spilled everything you need to know about this. Have fun!!!