Jump to content

Caleb

MODGRU
  • Posts

    37
  • Joined

  • Last visited

Caleb's Achievements

  1. That isn't what nuance is Duion. Likening not being rude in online forum posts to living in a communist run society shows a level of black and white thinking that is wildly detached from reality.
  2. I think you might be in need of some nuance.
  3. Let's steer back on topic shall we. . . Tech demos such as these are in essence a flex and often are never intended to suggest how things should be done. developing a framework that can handle millions of polygons and massive textures with dynamic scaling without a noticeable performance hit is impressive. Full stop. The best way to showcase it is to push it millions of polygons and massive textures. To me, the point of them demo seemed to be letting the engine do more and more of the heavy lifting. Dynamic global illumination, cave echos, flocking "boids," IK animations; it's largely taken off the plate of the artists and level designers and put onto the shoulders of the engine. Of course it won't be perfect and changing the industry standards will take time (if it ever happens at all). @Duion is probably right about a Torque showcase. There are things that Torque can do well and should show those things off. Being "small" or unique is immaterial. Having a good pool of art that is at least visually comparable to other engines is important, but I don't know if trying to prove to be Unreal's contemporary is a good idea.
  4. That's probably best. @Mitovo The problem you're reporting is certainly an interesting one, and whether it's an issue with hardware or art assets it's worth looking into. Torque3D has a nice profiler setup that might help point in the direction of the problem. Perhaps using profilerDump() on the Pacific demo and another demo would allow a side by side comparison. You can see someone else's dump here as an example. Also try playing around with the other metrics (specifically drawcalls) and see what that is showing. Posting the results here or linking to an upload might help some of the resident eggheads spot any issues.
  5. The resource you linked literally spawns another projectile. So spawning another projectile isn't a bad solution? Handling decals, sounds, and particles is why you WOULD want to create another projectile so you're not "reinventing the wheel" having to manually perform those steps. Accounting for material thickness and projectile deceleration is a matter of flavoring as far as I'm concerned. Not everyone's project will need that. @Sir_Skurpsalot If I remember correctly, the engine's projectiles use a series of raycasts to predict collision. Failing collision due to high speeds shouldn't be an issue. Using a single raycast from the muzzle is a perfectly viable solution to replacing bullets, but there is a trade off. In an online setting over long distances, it isn't crazy to think that a player may move out of a bullet's path after being shot at. It might be rare and no one may notice the difference, but a "real" bullet with "real" speed will account for these kind of scenarios.
  6. There are some interesting (if a bit passionate) ideas in here regarding the direction of torque, it's interface, and marketing. I think there's definitely value in them as well which is probably why @JeffR moved the posts into their own topic instead of simply deleting everything that went off the rails. There is a clear difference in perspectives here though. @Duion largely feels that getting more eyes on Torque as a viable engine would bring in more potential contributors. Sure there will always be window shoppers that don't add much, but is that really so bad? From what I can tell, @Razer suggests that some of these users might feel more comfortable getting their hands dirty with Torque if only it had a more friendly interface and tool-set similar to some popular options which they're already familiar with. I come and go with using Torque a lot, so from what I have seen it has undergone remarkable evolution in the past few years. For @JeffR, @Azaezel, @Bloodknight, and the many more individuals who have been dedicated to making that change happen however, I can imagine it gets more than a little old to see people come by, say "Cool but what the engine really needs is. . .," and then pass on through. Honestly, it is wonderful to see how much people care about Torque and want to see it continue to succeed as a viable open source engine. Let's just try to remember that just because you're right doesn't necessarily mean someone else is wrong. There's simply a lot of different people focused on different but important aspects. So let's all keep that in mind as we continue this discussion. TL;DR Play nice or this topic is going into timeout to think about what it's done. ;)
  7. It seems this topic has ran its course.
  8. The last few pages of comments have been rather tangential to the original topic. If we have more suggestions about the best way to handle update announcements and best practices, then consider creating a new topic for the subject.
  9. I like the plastic toy look you have going on. Keep on learning and keep on having fun!
  10. Community members treating each other with disrespect and immaturity is why a code of conduct exists for both Linux and here, how do you not see that as an argument? No, you somehow managed to miss your own point. Mitovo said "In my experience, CoC's are never a problem. . .", you disagreed with that quote in your reply and sited an example where there was also no problem with a CoC but made it sound like somehow there was. There wasn't. I pointed that out.
  11. "Scandal" is a bit of an exaggeration. Linus Torvalds didn't leave the project he took a 1 month vacation. the "computing world" was in 0 danger of being destroyed least of all because of the Linux CoC. Linus Torvalds treated people like dirt for decades and issued an open apology promising to change his behavior within hours of the CoC going into effect. No harm came from it, but some good might.
  12. I would suggest expanding the engine slightly as to allow you to easily get the transformed positions of nodes in the player mesh. I did this to approximate bullet collisions on players' limbs with really good success. In this way you can do ray casts to specific points on the animated skeleton (hand, elbow, knees, etc) to see if they're poking out of cover. I'm several engine iterations out of date now so I doubt my old code would be much use, but I'm sure you could poke around at how mount points are used as a jump start.
  13. Caleb

    I am discouraged

    I remember when I started molecular biology for my major (forever and a half ago). On the first day of class my professor told everyone to look to the person on their left and right because one of those people won't finish out their degree. It was scary to hear and he was right of course, but don't let statistics like that get you down. Some people took job offers in different fields, some got married and moved out of state, others decided they liked their minors more and switched majors, etc. The point is that there are enumerable reasons for people to switch/abandon projects, and not all of them are because they "failed." As @Duion said, set realistic goals. If you do that then there's no reason you can't finish your game. My advice would be to keep learning as much as possible, and keep going. If you enjoy what you're doing then don't stop just because other developers didn't reach their goals. Good luck!
  14. Riveting. @dstanton Try playing with the "cameraMinDist" and "cameraMaxDist" values in the player's datablock, or whatever the current equivalent is (I'm a few engine versions out of date).
×
×
  • Create New...