Please God allow us to search the Constructor forums

#41 certain things are not prioritized the way some of us would like

The funny thing about this part, being sure the product you sell works in the way it is advertised should be a priority. (Not 100% talking about Constructor here) Im talking about how much of the DIF and DTS art content functions can not be used because the exporters for them are so full of bugs.

The only priority should be to make sure that some type of continuity between what is SAID to work; is the same as what ACTUALLY do work. Some early complainant about DIF exporters were replied with how perfect Constructor would be in the regard of building a better export path. But the export path turned out to be Constructors weakest link. Its hard NOT to be disappointed, and mention it any time the chance comes up.

There is not any ONE DIF exporter yet that seems to handle all the DIF supported features. There is not any ONE DTS exporter that fully works. The art content exporting problem have been complained about in the forums going back beyond 2003, and here we have TGEA; TGB; TGE1.5+; Torque X; Torque for Wii... All new products built and marketed with the same underlining complaints still existing.

I dont think its right to talk about how "things are not prioritized the way some of us would like"; and how "*extremely* insulting to GarageGames employees" it is to point out what seems to be a growing trend.

I would be happy to just shut up about my ONE and only GarageGames complaint; but its a very old complaint, and i know im not the only one that have it. I actually DO think im done complaining about the same things over and over, at least until the next GarageGames product that i purchase do not preform as advertised.

Im sick of spending so MUCH of my time trying to get art content to work correctly with Torque....
It would also be nice to search the Constructor forums, and heck the forums search function in general do suck, but i did not buy a GarageGames product based on the forums search functions....

#42

Quote:I think most of us are more hops than scotch, although you never know :)

hmmm.. I kinda thought you guys where MadDog 20/20 kinda people! (even the thought makes me crindge) :P

..............................


Promised, not promised, what takes priority, and why certain things don't work I have no answer for. I know the blue collar guys at GG have very full plates, and pretty much bust their asses. I currently have a pipeline that is 0% functional due to the dif exporters/portal issues, so I can relate, and sometimes loudly. I know they are aware of these issues, and have plans to address them.. all I can do is hope that its sooner rather than later.

#43 I talked to Rick today and he said he has poked at it a few times and everything is set up correctly on the Google Mini so he has no idea what is going wrong. He is hoping to spend a little more time on it soon.

#44

Quote:The only priority should be to make sure that some type of continuity between what is SAID to work; is the same as what ACTUALLY do work.

Quote:Its hard NOT to be disappointed

Exactly. Not to hijak this thread, but this is what it all boils down to. The fact is that we've purchased a product that doesn't perform as it should and as promised. Can I live with small bugs in the interface and things like that... absolutely. But when I've wasted 100s of hours trying to get things to work the way they should, only to still fail... and all of this without simple documentation... it is very discouraging. This is not just Constructor (although a big part of it), but also the lighting engine and its faults. Again, both have great potential and I hope that some day (soon) they are fully realized, but until that day comes it's time to take a step backward and use other faulty programs, albeit more stable.

Enough beatin' the dead horse (cue up the G'N'R).

#45

Quote:
but also the lighting engine and its faults

Hmm? What faults? There have been no lighting related questions, bug reports, or criticisms since the TGE-A 1.03 release as far as I am aware...

#46 I'm not sure what he means by lighting faults.. cept maybe the light leaks everywhere regardless if you but brushs, bury brushes in each other, or overlap them. On another note, I see nothing "really" wrong with constructor per say.. it's the exporters that screw things up. It's not my first choice, but that has to do more with preference and style.

#47 Have you changed your light mapping settings? Most light "leaks" are due to larger lightmap settings that are causing overlap.

#48 The only thing I read in this post was Scotch... now I'm thirsty

#49 We're using TGE 1.5.3. "faults" was maybe a wrong word choice, but what I meant was that lighting is not all that great and easy to get the results that I want. It may be that I'm used to lighting within Maya, for example, but it would be great to have "area" lights to help simulate office lighting. Lighting DTS objects is also not a good as it could be... even with a light immediately under my florescent (sp?) DTS light model, it shows completely black, and requires ambient adjustments. Maybe I'm doing something wrong? Are there any good tutorials out there? Also, is there a way to have certain DTS objects not cast shadows (like doors, where I get multiple shadows on both sides of my doorframe when the door is closed.

And yes, it's true that the lightmap things with light leaking drives me frickin' crazy. I do not have ANY overlapping brushes. Everything was grid-snapped as I built it. I even have problems sometimes with simple DIFs. When the portals did start working, the collision was lost. As far as light scale, I've had to turn it down to 2 to get things woking nicely ... not sure if that is inneficient or what. It works in Constructor to go to 2, but other MAP editors crash on export with anything under 8... so that's definitely a plus for Constructor.

But yes, the lighting could be better.

#50 Grid snapping does not guarantee no leaks--in fact, if you are snapping two brushes to meet, it guarantees a (mathematical) light leak.

I'm not an artist, but light penetration points need to be blocked fully by a surface. I'll try a basic ASCII diagram:

|___

That is an example of two properly aligned brushes to not have a light leak from anywhere except underneath. If the "left side wall" was sitting on top of the floor, then that would leak.

Also, dts shapes as far as I am aware have to be flagged to receive dynamic lighting, and/or the dynamic light needs to be set to illuminate dts's. I'm certainly not an expert, or even experienced with the sg lighting stuff, but there is a good article on TDN about how to configure them.

#51 OK lol, let's settle this one right now if we can. Look at the pic below:





Which is the correct method that prevents light leaks. (sorry for off topic)

#52 From my experience....all of those setups will leak light Andrew.
- Even if there isn't any light to create a leak, the leaks still appear and they do it magically by the hand of god.
((Too bad I can't edit the lightmaps in photoshop. )) That would be a nice feature....external lightmaps.

OK, by my count, TGEA and DIFs have the following MAJOR issues;
1. light leaks
2. Rigidshapes can't pass through portals
3. flipped brush faces
4. random compiled tris cutout and flipped
5. I am sure there is more...

So, Is there any chance that we can have the TGEA-Legacy-Dif exporter source ? (*The one that supports portals)

That would be great.

P.S. There is no need to yell at me or call me names...my post is made upon the basis of USING FACTS.

#53 Andrew, If I'm not mistaken, I have tried them all... well, except for number 2 with the intersecting brushes, kind of. The problem is that I get leaks in many locations no matter the method of creation.

As an example, I first built the walls as in number 4... leaks.

Then I thought I'd be wise and build it like number 1 with the angled brushes... certainly that would work... wrong.

In the case of number 3, I essentially have that in the "support beams" that run along the underside of a solid ceiling brush... but the leaks show on the support beams in that case too.

And as I've said, I haven't really tried number 2, but I did notice that by accident I had intersecting brushes... in that case I don't remember if it was leaking in the particular place, but I don't think so, only because it was in the middle of the building under the floor.

So I have to agree with erb, they [u]all[/u] leak light. With that said, I'm assuming that number 3 is the best method?

To add insult, I took my SAME file and exported from a .MAP file and a .CSX file. The number of zones in the .CSX file were almost double that of the .MAP if I remember right, based on what the text file says upon exporting. In this case, the .MAP did not have the portals properly working at all, and light leaking was abundant. The .CSX apparently had portals working because all was dark, but ONLY after putting the light scale down to 2 (at 8, i believe it was, there was light leaking). However, at 2, every room I went into delivered a house of mirrors effect on the whole screen. Back to the .MAP file... it also had a house of mirrors effect, but only in certain rooms (possibly someone was right in another thread about 2 portals on the X axis don't work?).

I'm not trying to hate on Constructor, either guys. In fact, I LOVE some of the features it is trying to implement. But when it doesn't work at it costs me time (which we all know "= $"), that makes me very upset and cranky. What makes me even more cranky is that people try to defend this garbage sometimes (I'm talking in general on the forums, not necessarily this thread) to an extent that they won't even listen to ligitimate concerns. We all want one thing and one thing only... A SOLUTION. If we can't search the forums, then maybe it's time that someone write up DETAILED documentation on the functions, bugs, workarounds, and general workflow patterns that actually work.... and post that so the community has access to it. Unfortunately, many of the docs that I've come across or went looking for either don't exist or are lackin any real direction, and sometimes assume too much or fail to mention key elements, leaving us scratching our heads. --off topic-- but "mountPoint" is a key example of this lack of consistent and working documentation. This feature is broken, period. If it is working, why is it so obtuse trying to figure out how it's working (rotations, specifically)? Is there documentation that has helped us... no, and yes, we've searched our bloody heads off.

-- back on topic -- The point is that Torque and Constructor are great tools, but I'm beginning to wonder if there is anyone out there that knows how to take advantage and use some of the most basic features. If these people ARE out there, could you please enlighten the rest of us, so that we aren't wasting countless hours/days trying to reinvent the wheel? Wouldn't it be great to display some of the great work that people are doing instead of frustrating them into submission and giving up?

#54 I would recommend using another application, say Quark or 3D World Studio, until the problems that you are having with Constructor are either fixed, documented, or worked around. If time is money, then you should spend that money elsewhere to get your project done. Not the answer you want, I know, but that's the only sane answer. It would also be good to note all of your problems in a concise manner in a topic so that they can be addressed, even if you move to something else. You don't have to, though it might be helpful to others as work-arounds or fixes come out. But I would strongly recommend using something else if Constructor is not working for you and your workflow. That only makes sense. It is not like there are not other options out there that have been working for a long, long time.

#55 David, with all respect, that answer.. is no answer. I've tried to tell you that. It does not matter if you use constructor, quark, Radiant.. it's the EXPORTERS. only ONE exporter "handles" portals for TGEA... this eliminates the functionality of all the others regardless. So, we have no choice but to use constructor because the only exporter that "handles" portals is hard coded into it.

Quote:It is not like there are not other options out there that have been working for a long, long time.

Thats exactly what the case is right now. :(

(not trying to be rude David, pls don't take it that way)

#56 I thought the legacy TGEA exporter supported portals. If that is the case, then a healthy look into the map2dif code should be a project priority, especially if GG does not have time to make it a priority. I wonder how other TGEA projects are dealing with the problem. Perhaps LOD. I don't know. Perhaps they have moved to another engine.

But most of the people I've seen who are unhappy with Constructor and are still using TGE, and there is absolutely no reason that they cannot use another application if it is the sole reason their project is at a stand-still. Quark has been fully functional for a long, long time. People just hate using it. 3D World Studio is functional. People just hate paying for it. Radiant is functional if you are a Mac user and steer clear of curved surfaces. Of course, that is for TGE. And you will have to place your DTS models in the world editor, just like we had to before.

#57 David,

I am very familiar with radiant and am currently using it for construction. I am also familiar with Quark, and have used it as well. I am familiar with 3D World Studio, and am not using it though. The Legacy map2dif TGEA exporter is the exporter for TGEA that is suppose to handle portals, though it's functionality is very limited and needs addressed if you are making anything complex. Most people (I believe) are making mainly exterior levels with very limited interiors. We are making complex interiors with very limited exteriors, hence the need for functional portals, and ALOT of them. LOD is overall useless in such a scenario. Placing our DTS's in the world editor is fine, and definitely is a working approach. We would love to look at the Legacy map2dif TGEA exporter.. but that is not an option I guess right now.

So, at this point, regardless what we use, it comes back to the same point. There is no pipeline until the exporter(s) are addressed. We do not want to go to another engine because we love TGEA and believe that it is the engine that will allow us to achieve our goals. I do NOT want to have to switch to another engine because of exporters.

#58 Exactly ... we are finding a lot of good functionality for our project in TGE too. We've talked about getting TGEA, but have yet to do it. So, if I understand this correctly, things work BETTER for TGEA, but the portals are hosed? Our projects are typically like Andrews... much more to do with interiors than large-scale outdoor environments.

So am I also to assume that TGEA and Constructor 1.0.3 work well for baked DTSs? I haven't tried lately, but I was having serious issues with that.. lost collision on DTS shapes to name one. But the most serious one is that DTS shapes are NOT occluded within the DIF buildings when baked in, which eliminates the benefits of not having to place things in the world editor.

Besides, either I didn't express myself well, or forgot to, or it went unread, David... I've exported from Quark (after fixing the interior up so that Quark would even export it ... something's afoot in Constructor's .MAP saving), and the light leaking was horrible... which is why I love the fact that I can scale Constructor's light scale down to 2 (Quark crashes below 8).

#59 In the above diagram i use the #2 method most often. But that method excludes any of the map2dif exporters made from Constructor's birth onwards (only good for OLD map2dif 'classic' and one version of the map2dif+ also map2difRAD debug handles this type of geometry). Also sometimes im forced to forget BSP lights, and just use dynamic in game placed lighting (not as dramatic, but far fewer ugly BSP problems).

So you see, light leaks are more WHAT you export with then HOW you build your geometry.

If one is in the need of PORTALS so very bad for TGEA, why not build yourself an OCCLUSION class object that you have custom control over? I know with TGE most of its object occlusions decisions are made in one function, (sceneTraversal.cc? something about terrain check if i recall correctly.) As TGE truly one have ONE occlusion type- the terrain(am i wrong about this???); BSP zones are different.

There is also Alpha LOD, I use something based off this, to take care of all my LITTLE details, and some other tricks to take care of my BIG details. Add in the default LOD systems and some careful design you will be amazed at what you can get away. All of the optimization systems i have do add extra CPU time to the project but in the end i can have alot more in game detail then before.

#60 @Woody
I did not remember seeing you mention Quark at all in this discussion. It doesn't mean you didn't, I just don't remember reading it. It has been a long time since I used Quark, but I don't remember it crashing on lightmap problems. I did some horrible things when mapping for Half-Life in Quark, but haven't had much difficulty with it--not that I've used it in a while.

But I did not think that DTS occlusion was on-board for Constructor, but placing DTS's was more a matter of convenience for level designers who did not want to use the World editor from detailed interiors. I may be wrong, but I just didn't remember ever hearing about occluding DTS shapes. What are you making your DTS shapes in? I haven't had DTS collision issues. Are they overlapping a brush and perhaps losing their collision volume to the brush instead (I have no idea and am just speculating right now since I haven't seen that particular issue).

@Caylo
Alpha LOD is a great resource.