chriscalef

Hm, but ScatterSky is just sky, with procedurally interpolated colors, correct? I'm thinking more in terms of replacing a skybox that includes distant terrain, so I would need an actual image mapped to the inside of a sphere. But anyway... not my highest priority at the moment, but certainly of interest in the future. Thanks for the link, @JeffR!

Well that does sound quite interesting! Say, while we're on the subject, can anyone tell me anything about what might be involved in order to implement a skydome instead of a skybox? I searched around on this site and garagegames, and didn't find much, but apparently this guy has done it. Not sure off the top of my head how to create a hemispherical image, but it's obviously a problem that's been thoroughly solved by now. Beyond that wouldn't it just mean drawing a spherical object in place of the box, and inserting it at the same place in the render?

I don't know the one line fixes all solution, but here's an example one liner for forest brushes... void ForestBrushTool::setSize( F32 val ) { mSize = mClampF( val, 0.0f, 15000.0f );//instead of 150.0f... Con::executef( this, "syncBrushToolbar" ); } Re: some of the other items, I know it's not production ready but I'm definitely working on the terrain paging thing, and have PhysX vehicles on my roadmap although I can't commit to a date for them yet. Also interested in several of the other items. But unless it means moving over to C#, which is already pretty well established, good luck with pushing another scripting language.

Aha! Issue located! And, apologies, it *is* in the engine. :oops: But it is not a property of the dts format, it is coming from the collada importer. Apparently, if your collada file has animations organized into "clips", then it will load your sequences with their own names, otherwise it puts together all the "library animations" into one default clip it names "ambient". Here's the relevant source, from ts/collada/colladaImport.cpp: DefineConsoleFunction( enumColladaForImport, bool, (const char * shapePath, const char * ctrl), , ... // Get animation count for (S32 i = 0; i < root->getLibrary_animation_clips_array().getCount(); i++) { const domLibrary_animation_clips* libraryClips = root->getLibrary_animation_clips_array()[i]; stats.numClips += libraryClips->getAnimation_clip_array().getCount(); for (S32 j = 0; j < libraryClips->getAnimation_clip_array().getCount(); j++) { domAnimation_clip* clip = libraryClips->getAnimation_clip_array()[j]; tree->insertItem(animsID, _GetNameOrId(clip), "animation", "", 0, 0); } } if (stats.numClips == 0) { // No clips => check if there are any animations (these will be added to a default clip) for (S32 i = 0; i < root->getLibrary_animations_array().getCount(); i++) { const domLibrary_animations* libraryAnims = root->getLibrary_animations_array()[i]; if (libraryAnims->getAnimation_array().getCount()) { stats.numClips = 1; tree->insertItem(animsID, "ambient", "animation", "", 0, 0); break; } } } So blender must be saving out anims as library anims instead of as clips, I guess.

Ah, well that's it then! Interesting. There's an "action strip" editor? I know literally nothing about blender, I've fired it up to convert some models and that's the extent of it so far. :-p But being open source, I'm sure it wouldn't be that much of a stretch for somebody to add independent sequence support. Or just keep working around it, since you've got a functional workaround already. You could also use that tsshape::write function to save it the model with individual sequences, after you've already split your ambient sequence once using your current method.

Interesting. Well, it must be the blender exporter doing it, then, because Torque definitely does not do that. Can you send me a sample dts that you've exported from blender with sequences on it? Or check it out yourself in hexedit - it's free and it will tell you what's on the actual dts file, without ever loading it into Torque.

The answer is number two. TSShape::write saves a dts model that has sequences loaded onto it from individual dsqs, assembled with a shapeConstructor. When this model is written out, it exports as a list of separate sequences, with no necessity for even one of them to be named ambient. When you reload this file, it loads all its sequences in a list, there is no combining them into one ambient sequence and then breaking them up again. Again, I am only speaking of what the engine does, however, with TSShape::write. What you are experiencing, I'm guessing, is a convention used by your particular exporter. As stated, I spend most of my time in Visual Studio and don't know much about the exporters, and I also don't own any of the art tools beyond Blender, so I'll have to leave it to others to figure out which of the exporter(s) do this thing.

So, some progress here to report back on. First off, so far so good with the mountObjectEx branch from OTHGMars! I would heartily endorse inclusion of this branch in the main tree, barring some lurking problem that has not shown itself yet. I'm still working out my system and deciding what should actually mount where, but my first pass involves a new physicsShapeMount table in the database, which allows me to load up any given physicsShape with as many (currently TSStatic) models as necessary. I'm having some trouble mounting physicsShapes onto other physicsShapes at the moment, not sure why, but I don't expect it to be serious. Anyway, here's my helicopter with the first round of mounts: http://opensimearth.com/images/screenshots/ka50_propdisc.jpg The blades still look stupid because they are made up of multiple overlapping meshes, and we're seeing all of them at once. However, the exciting news from yesterday is that I discovered the setMeshForceHidden() function in TSShapeInstance, and exposed it to TSStatic, as per this discussion, and now I can turn any meshes I want on or off at will! There are three levels of blades on my ka50 model. The general idea is that when they spin faster, they switch to the broader shaped blades, and it makes the blur look better, but when they slow down enough to be seen they need to switch back to the actual blade shape. The three levels are: the actual rotor blade, a larger "propblur" shape, and an even larger "propdisc" shape. The above image was the propdisc, and here's the propblur: http://opensimearth.com/images/screenshots/ka50_propblur.jpg And here's the end goal, the actual blades themselves. Also, I got the tube rockets installed, but I haven't gotten to all the other individual rockets. I'm still trying to figure out the xml files that define all these mount positions for flightgear, so much of the placement here is still manual trial and error. http://opensimearth.com/images/screenshots/ka50_blades.jpg An attentive eye will note that the center of the blades is not exactly aligned with the rotor. This is because the rotor is tilted forward five degrees, and my next step is to get the blades aligned with that, but first I have to decide whether it makes more sense to attach them to the rotor first, and then get that tilt for free when I mount the rotor, at the cost of making my hierarchy that much more complicated, versus adding some nodes to the helicopter and adding everything separately to those nodes. I'm leaning toward the latter solution.

Okay, I'm very sorry to keep beating this horse, but it is absolutely not dead yet, and it keeps kicking me. :-) After all the years I've been with Torque, I get very disturbed when I learn new "rules" that I've never heard of before, and I intend to lay this one to rest here and now. The issue we are discussing with the ambient sequence has to be an exporter issue, not an engine issue. I have admittedly almost no knowledge of any of the Torque exporters, because I am not an artist and don't work with exporters, so someone will have to fill me in on which one(s) do this thing of forcing all sequences into one named "ambient". But in the engine itself, there is *nothing* magical about the ambient sequence except for the fact that it often gets played by default. TSShape has a function called write(), with which you can save the model to a dts file, and when you do this on a shape that has sequences loaded, all of the sequences get saved out, with their names, and there is no stuffing them into or introduction of a special sequence called ambient. Here is a model with four named sequences, none of them ambient, created with a cs file and independent dsq files. http://opensimearth.com/images/screenshots/m4_with_seqs.jpg Here is the cs file with which I constructed this model, and to the left you'll see the new model I saved with the write() function, called M4_seqs. http://opensimearth.com/images/screenshots/m4_cs.jpg You will also note that there is no M4_seqs.cs file, meaning when I next load this model into the engine via creating a new TSStatic, it will have no shape constructor to load sequences. Here is my new model, with four working sequences, none of them named ambient. http://opensimearth.com/images/screenshots/m4_export.jpg And just to make sure the horse is good and dead, here's a screenshot from hexedit, examining the M4_seqs.dts file itself to make sure the sequence names are all there, and ambient is not. (Look toward the middle of the column on the right, you'll see TPose, root, idle etc.) http://opensimearth.com/images/screenshots/m4_hexedit.jpg So, while I do not doubt that one or more of the exporters force you to do this thing, I trust I have made it clear enough that the engine does nothing of the sort. Ambient is entirely optional, and it is very much possible to store multiple named sequences in a dts file without any of them being called ambient. PS: if anyone wants to know how to use TSShape::write, it's very easy. Here's a sample method I put into PhysicsShape, but you could do a similar thing from TSStatic or ShapeBase or many other places. DefineEngineMethod( PhysicsShape, write, void, (const char *filename),, "@brief \n\n") { FileStream *outstream; TSShape *kShape = object->mShapeInst->getShape(); if ((outstream = FileStream::createAndOpen(filename, Torque::FS::File::Write))==NULL) { Con::printf("whoops, name no good!"); } else { kShape->write(outstream); outstream->close(); } }

lol

Oh, sorry, now I understand the confusion! I'm talking about a live model in the engine, you're talking about the saved model file. And I didn't know that about saved models, now I gotta run check that out...

I think the cause of your problem here is most likely the StringTable. I could be entirely wrong here, but I think this is what's going on: Torque is generally not case sensitive (at least to and from the console), and it stores strings in the StringTable so that it can reuse them when it sees them again and doesn't have to waste space store redundant strings. However, a side effect of these two facts is that if there is already a "Run" in the StringTable, and then you try to use the word "run", it will fall back to its original "Run" instead, viewing them as the same word. Again, this is just a theory, but I have reason to believe it may be correct.

What BloodKnight said. I have no particular attachment to being right here, but I would not want newcomers to leave confused, and from my understanding of what's been said here and of what goes on in the engine, you're precisely not right, @Duion. I guess it depends on what you consider a "sequence", but from the engine side, each TSShape has an array of sequences, each with its own name. There doesn't even need to be an "ambient" sequence at all, if you don't name any of them "ambient". It is true that each shape keeps one big list of all the transforms (really two lists, nodeRotations and nodeTranslations), and each sequence stores a starting point in these lists, and a number of frames. So if you want to call those lists "a sequence", then yes, all sequences are part of that, but that is the only way I see in which you could be considered "right". It seems more helpful to me, however, to treat individual sequences, having separate names and being stored in separate dsq files, as distinct and not as one big sequence, since the only real connection is that internally they are all kept in a big list.

Interesting. Sorry, I'm coming at it from the code side and am apparently not familiar with the way a lot of people work. What I'm accustomed to is having a lot of individual sequence files, and then packing them on the character in the shape constructor, ie function SoldierDAE::onLoad(%this) { %this.addSequence("./Anims/PlayerAnim_Lurker_Back.dae Back", "Back", "0", "-1", "1", "0"); %this.addSequence("./Anims/PlayerAnim_Lurker_Celebrate_01.dae Celebrate_01", "Celebrate_01", "0", "-1", "1", "0"); %this.addSequence("./Anims/PlayerAnim_Lurker_Crouch_Backward.dae Crouch_Backward", "Crouch_Backward", "0", "-1", "1", "0"); %this.addSequence("./Anims/PlayerAnim_Lurker_Crouch_Forward.dae Crouch_Forward", "Crouch_Forward", "0", "-1", "1", "0"); ... } And then just playing them by name after that.

What do you mean "there are no other sequences"? Ambient is one sequence, with its only special behavior AFAIK being the fact that it's the sequence that gets played automatically in many cases. However each TSShape can have a large array of other named sequences, each with its own set of keyframes stored in the nodeRotations/nodeTranslations vectors. Obviously you've done a lot of character animating, so you know about multiple sequences on a model... so I must be misunderstanding what you're saying?

Yes, tsStatics and PhysicsShapes at least can play their ambient sequences by default, which can be really handy for background animation on stuff in the level, without having to go to the trouble of running it all manually. Not sure what you mean @Duion about "when you animate a model", because this is only for the ambient sequence itself, you should give other sequences their own names.

Looking good!

Regular sun, here's the specifics I was using: new Sun(theSun) { azimuth = "125"; elevation = "70"; color = "0.968628 0.901961 0.901961 1"; ambient = "0.078431 0.113725 0.156863 1"; brightness = "1.0"; castShadows = "1"; coronaEnabled = "1"; coronaScale = "0.5"; coronaTint = "1 1 1 1"; coronaUseLightColor = "1"; flareScale = "1"; attenuationRatio = "0 1 1"; shadowType = "PSSM"; texSize = "1024"; overDarkFactor = "3000 1500 750 250"; shadowDistance = "200"; shadowSoftness = "0.25"; numSplits = "4"; logWeight = "0.9"; fadeStartDistance = "0"; lastSplitTerrainOnly = "0"; representedInLightmap = "0"; shadowDarkenColor = "0 0 0 -1"; includeLightmappedGeometryInShadow = "0"; position = "0 0 0"; rotation = "1 0 0 0"; scale = "1 1 1"; canSave = "1"; canSaveDynamicFields = "1"; bias = "0.1"; Blur = "1"; enabled = "1"; height = "1024"; lightBleedFactor = "0.8"; minVariance = "0"; pointShadowType = "PointShadowType_Paraboloid"; shadowBox = "-100 -100 -100 100 100 100"; splitFadeDistances = "1 1 1 1"; width = "3072"; }; Observed behavior was fast and irregular flickering, which oddly enough stopped when the camera was facing due south (minus Y). Facing any other direction, both the grass and the transparent windows in my helicopter flickered at the same rate. I'll try to reproduce it on a stock build and poke around at it some more this weekend.

Whoops, thought I posted this last night, but anyway, mountObjectEx offset transforms check out as well: http://opensimearth.com/images/screenshots/mountobject_02.jpg

So hey, I'm working today and didn't have time to test it extensively, but when I updated to 3.8 I got a weird lighting effect. In a level with a sun object and a grass object, the grass as well as other transparencies flickered really bad. When I removed the sun and replaced it with a point light went away. I haven't had time to verify this in a stock build though, so odds are high it's something local, but I thought I'd mention it in case anyone else sees it.

Results: my fault! (What a surprise.) The problem was a bad merge decision which ended up kicking us out of necessary mount-related code if we didn't have an ambient sequence. (oops) Still got a ton of work to do on the modeling end, of course, including finding the proper node to attach the rotor, and addressing the mount transform issue, but we do have a working two level hierarchy here, with the blade attached to the rotor, which is attached to the helicopter. http://opensimearth.com/images/screenshots/tsstatic_mountobject.jpg

Well, I got a chance to do some more testing, and have found that as a matter of fact one (and only one, unfortunately) of my test models actually is capable of being mounted onto another shape. For some reason the Michael4 character model can mount just fine on both physicsShapes and tsStatics, while performing his animations uninterrupted. Which is a nice little ray of sunshine. Now, on to figure out the secret sauce...

Right on, thanks @Bloodknight. I was gonna go there next anyway, but I went ahead and did my long awaited merge of 3.8 first, and then merged the mount_object_ex branch. Which, after a few conflicts with the physx branch in tsStatic.cpp, went pretty smoothly. However, on first test, I can't tell if it doesn't work or if I'm simply doing it wrong. I'm trying to mount a tsStatic to another tsStatic, for first pass, and I think it crashed the first time I tried, but on second and further tries it doesn't get a crash, but I get no apparent mounted behavior, ie I move the object I mounted the second object on, and the second object doesn't move. Will look at it more later but out of time for the moment.

Does the chart in #680 still apply? i.e. it works for ShapeBase, but not tsStatic, etc? If so, is there still a plan to generalize this functionality up the hierarchy?

I've never done anything on my own with mountObject, but now I'm finding a pressing need to make it work. I've been testing on tsStatic, but ultimately I'm going to need to do it with PhysicsShape (or, GameBase if we want to go deeper, unless it's going to go all the way down to any SceneObject). I just discovered PR #680 and I see it on the list for 3.8. Did it make it in? I'll have to DL and test it, hadn't gotten around to it, but am curious if anyone has any help for me on this issue anyway. For example, do we still need nodes named "mount0" etc or can we just mount to any node now? And does the mounted shape still need a "mountpoint" node? Or is all that just the ShapeBase implementation?