Hiding items based on triggers.

#1 You can use %obj.setHidden(true or false);
For the smoke you can use a particleemitter and add/delete it to get the effect.

#2 Thanks. I figured I'd have to play games with add/delete on emitters. What I can do is create the emitter in the mission editor, steal the transforms and then just create them in code. This conclusion came to me once I put it down for awhile.

I decided also that I could use some Bourne shell script to create Item::-based cs code for each static item based on the .dts file names so that they have .cs code related with the .dts shape files (ItemData-derived items, like Healthkit have more capabilities than TSStatic items). We'll see how that works out.

Thanks for replying.

#3 Unfortunately, %obj.setHidden(true) does not appear to work on a TSStatic object. How do you get a TSStatic object to go hidden?

Thanks,
Jeff

#4 You are right , its not a ShapeBaseObject .
Can't you use StaticShape for this ?
I dont know how to hide a TSStatic .

#5 I finally settled on creating an object that is ItemData-based. The problem with it, though is that there does not appear to be a way to collide with it and stop. You can pick up the onCollision event, but I'd like to support an object that does not exist until triggered to then be something the player can bump into.

Think about a door that does not exist until the player steps on a trigger. Then poof, it's there. Now I'd like the player to not be able to walk through it.

One thing I tried that seems to work is to create the static object in the mission using the world editor to position it the way I like. Then I cut the new TSStatic() datablock out of the mission file and paste it into a trigger. Step on the trigger and the impassible door is there. Fire another trigger and you can use %obj.delete() on the TSStatic door and the door goes away. Not the most elegant solution, but it seems to work.

#6 Why dont you use a staticshape for doors ?
It has collision and you can hide it and animate it if you want.

#7 Jeff,

I may be misunderstanding your needs -- correct me if I am. I know you specifically requested a scripting solution, but if I were trying to make a treasure chest illusion, I would want to go entirely codeless and scriptless. Here's how . . .

I would manipulate the .DTS LOD configuration to create the "always out of reach" effect that you mentioned. When using .DTS shapes at 1 - 128 pixel sizes, a treasure chest could swap LODs just like most objects do -- increasing detail along the way, but as the player gets closer to the prize, the LOD sub-objects could become progressively more transparent. Then, as players move farther away, the effect reverses itself, ultimately revealing the treasure as nothing more than a disappointing illusion. If used sparingly, and in the right places, it shouldn't affect frame rates very much.

While I'm on the subject, similar techniques could be used to hide walls, doors, traps and other obstacles. If used well, this technique might also lend itself to hidden/camoflaged AI units. A stone gargoyle could be just another decoration -- until the player moves closer.

In case you're wondering, I'm a code-clueless and script-deficient artist kind of guy. :)

Aaron E.

#8 Billy,

Yeah, that's what I was saying with the TSStatic() datablock solution. I just cheat by stealing the correct placement by first creating it in the editor and copying the text for the new TSStatic() from the .MIS file and putting it in script. It works.

Thanks.

#9 Aaron,

I am the opposite. I've been a programmer for nearly 25 years but art baffles me. I'm just beginning to get the hang of all the things I have to do to make Torque and Max work together. I've been messing with LODs lately for better performance, and maybe you can tell me why I sometimes get a model that only changes LODs in the Show Tool (I've tried it in both ST Pro and the old command-line tool) by explicitly moving the detail slider-- auto LOD changes don't happen on their own. This only happens with SOME models. I'm using detail levels of 10 and 2, and for some models, I can walk right up to it and the LOD never switches from 2 to 10.

What part of the problem may be is that I'm using what I consider to be a "Stupid Torque Trick" (who knows, there's a book in there somewhere...). I've noticed that when I detach the lower resolutions from the Schema view base01->start01 node, I can delete some of the sub objects in the lower resolution (outside the hierarchy) and they don't get drawn at lower LODs. This may be the problem. The missing objects may be causing the autoDetail not to function properly.

Let me explain, some of the models I use have a LOT of polygons, and if a single object has more than say, 10K polygons, DTS export vomits. So, I sometimes split up objects into sub-meshes-- LFoot10, LShin10, LThigh10, etc. What I'll do to eliminate a LOT of polygons at low LODs is to delete, say, the LFoot2 object altogether (or another trick I've tried is to "hide" the lower level detail objects by grouping them together-- which causes the exporter to skip over them since they are not parentless). This makes, say, a foot (which no one notices very much until you get close) not get drawn at great distances, but only show up when the player really closes in on the object.

Funniest thing, in all the documentation I've read, I've never seen a good definition of what the detail levels mean. One definition says that the detail level determines how many polygons are used when the object will appear as X pixels in height on the screen, where X is the detail level. But if you read about how the autoLOD settings in the config file work, it's definition seems to contradict the pixel height theory. It's all just theory.

#10 Jeff,

It's taken me a while to respond to your last post. My new laptop arrived this afternoon and I've been getting everything set up perfectly.

Yes, like you, I'm just beginning to learn the art of DTS shape exporting. Only in the last few months has it started working for me. I'm using gameSpace but my partner (also named Aaron) uses Max and we have both run into problems exporting to Torque. So here's what we've discovered so far . . .

Whenever we try to export large models (11,000 - 15,000 triangles) we end up with really strange vertex placement, often around the feet of our character models. Most of the time, it looks like several vertices are converging on a single point. This has happened when exporting from both gameSpace (for me) and Max (for the other Aaron). Here's an example of one of our guys. Notice the wierd mesh mess occurring at his feet. I think he was about 12,000 polygons.


However, on the high end, at around 20,000 polys, the gameSpace export completely crashes out on me without producing a .DTS file. I don't know if Aaron has tried anything that big though. And I haven't tried exporting large/huge poly count regular shapes (like cubes and spheres) to see if they work better. So it may be something special for complex shapes with lots of faces.

When we first ran into it, we assumed that the problem was in the design of the model, but having experienced similar results from other high poly count character models makes me think it's a problem with the .DTS file format. But, that's just a guess. Maybe someone on the boards can explain the cause for us.

I've tried automatic LOD generation a couple of times, but since I'm a control freak, I don't use it. I've got to have more control over meshes than the autoLOD function seems to offer. Maybe I should get counselling for that. :)

As for the size 2 and size 10 LOD switching problems, I just tried one in g/s and it worked great for me. But in your post, you mentioned that it happened only on a few of your models. In that case, it could be a little tough tracking down the problem. If you posted one of your offending shape files and a Max export log for it, maybe someone can figure out what's going wrong.


About the LOD theory stuff. I've done some experiments with it and it seems to work as advertised (pixel threshold switching). My test methodology could be completly wrong, but here's how I did it. 1) start up Torque and drop an LOD'ded object onto the terrain 2) pull up the Torque console and type GLEnableOutline(true); to slip into wireframe mode, 3) walk toward or away from the object until an LOD swap occurs 4) take a snapshot with the CTRL+P combo, 5) close out Torque and examine the screenshot with a decent image editor. Or crop the image to only include the LOD object mesh image and figure up how many pixels wide or high the model was on the screen at the time of the LOD switch. By doing it this way, I've found out that my LOD objects really are swapped at the threshold that I configured for them in gameSpace.

If any pros are reading this message, then they are probably rolling their eyes right now. :) I guess that's one of my "Stupid Torque Tricks". Anyway, I hope this helps somehow. And I hope I'm not too far wrong with my descriptions/suggestions.

Aaron E.

[edited typos]
[edited for clarification]
[edited broken link]

#11 Thanks Aaron. I'll try the GLEnableOutline trick.

I'm going to try to fiddle with Max a little to figure out the LOD switching issue. I'll post the max/dts if I give up. I was just curious if you had fun into the problem.

On the other issue you described, I call it "sproinging" the model just seems to sent out fragments into infinity (with the texture still remaining true to the mesh). The fix I've had to apply is to subdivide the mesh into smaller pieces parts and then export them. They still appear to be the same object within Torque.

#12 Jeff,

Yeah, there are all kinds of ways to test that, but the wireframe trick is probably the easiest way to experiment with LOD from within the engine. It helps me pinpoint my mistakes -- which occur way too often.

I wish I could have helped with the Max-specific issues. Maybe one day I'll be able to afford Max. But I'd probably be lost trying to use it. I've been modeling with Caligari products for over 10 years, so creating my stuff with gameSpace feels really natural to me.

Sproinging. Interesting word. Yeah, that's what we've encountered. And chopping up models eliminated the effect for us as well. We've settled on lower resolution models now, though. Our current target audience really can't handle all the polygons we would like to throw at them. I wish I knew what caused the 'sproinging' issue -- maybe then I could prevent it rather than having to work around it. Maybe one of the Garage Games guys can fill us in on what's causing it.

Now that I think of it (and the Torque devs), I'm wondering if large poly count models do the same thing in TSE as well as TGE. With normal mapping of low-resolution objects, it might never become an issue -- but could TSE handle big meshes if a specific project required them? I'm sure these are questions for the GG guys though.

Anyway, sorry for the ramble. And, hopefully, a solution will turn up for your LOD problem soon.

Aaron E.

#13 ...

#14 Excellent. I'll try it out and give you a post back with what I find.

Thanks.

#15 @Jeff

Quote:
I'm using detail levels of 10 and 2, and for some models, I can walk right up to it and the LOD never switches from 2 to 10.

Is this when you are really close to a model.
When i do my lod i check the max pixel size ,when im really close to a model if i have around 500
i set my first lod info to 500 and goind downwards and at 2 pixel size it disapear.
But this sound like reverse what you doing.
I tested this in the showtool and in the game both is displaying right sizes.

#16 Tried the change suggested by Mr. Greenawalt. No luck. Still sticks at detail level 2 in the old (non-pro) show tool. Let me just try firing up the regular game and see if the detail switch happens.

#17 ...