What happen to fxRenderObject?

#1 I have been asking the same thing since 1.7.0.
It would be very instructive to have one for 1.8.1.

#2 Caylo, I've got fxRenderObject, fxCloth, and fxStringObject for 1.7.1, but they are all "WIP", they compile, but dont render, I cant get past a few of the GL to GFX calls, but they are about 90% done.
if you want, tell me by email

#3 @deepscratch , I am pretty much at the same place as you.
Got them to compile but not render.
I just don't know enough about how 1.8.* renders.
There is a difference in rendering from 1.7.* to 1.8.* that also makes problems for porting code from TGE to TGEA.

I had a pretty firm grip on TGEA 1.0.3 then 1.7.0 came out and alot of my code from 1.0.3 just won't work.
I then spent alot of time on trying to understand 1.7.0's rendering pipeline then POW 1.8.0 changed the rules again.

A little frustrating to say the least.

Seriously, fxRenderObject for TGEA 1.8.1 is a must have resource.

#4 1.8.1? hell, I'd like to get it working properly in 1.7.1
I'm putting off porting my project over to 1.8.1 for now for 2 reasons,

1: I cant get physx joints working in 1.8.1, got the rest working though, but without joints, whats the point?
2: the vast degree of changes I've made to the source code are overwhelming, I'm to bloody scared to start the port!!!

#5 I do agree a fxRenderObject for TGEA 1.7.1 should be made but I doubt GG will back step to 1.7.1 and create a resource for it.
It will likely take a indie member to create a 1.7.1 version.


I too have a lot of 1.7.1 related code I have put off moving over to 1.8.1 out of fear that the next release of TGEA(if there is one) will make porting to the newer version as difficult as from 1.7.* to 1.8.1.

#6 I ported fxRenderObject to 1.7.1 some time ago, when I was porting fxSwarm. I haven't yet ported it to 1.8.1 (and I may not be able to move forward to 1.8.1 now, like I planned, since it no longer supports Zip files). But I'd be happy to email someone fxRenderObject - with the caveat that I don't recall if it works or not (i think it does... but not 100% sure).

#7 @Jaimi,
I would love to get that 1.7.1 port, could you mail it to me?
snotporridge@yahoo.com

#8

Quote:
(and I may not be able to move forward to 1.8.1 now, like I planned, since it no longer supports Zip files)

Let's have some faith. As far as I can see, Alex just noticed.

#9 @Bill Vee;deepscratch; and all the rest who care to include themselves;

I know how you feel. I got 1.3 as a toy with no solid game design doc as a goal. I figured anything i did to TGE would be 'just fun with a new toy', but after adding many 'fun' resources, then upgrading to TGE1.4 and learning how to "PORT" I was able to exercise my new skills once again when i moved to TLK, only to take the full lump of snot upto 1.5- who i then totally killed with a ignorant attempt at the impossible, and lost the will to bring it back to life(sure i could restore a backup, but TGE just would never be able to do what i actually wanted, under my limited programing command).
I held off on TGEA until 1.8 and i figured i could actual use my perpetually growing knowledge to accomplish my finally now completed Design Document, how could i go wrong useing the flagship (and most complete) Torque Engine version ever!?
I was never expecting to "PORT" my TGE1.5 code into TGEA, but just rewrite what I needed tuning it to my specific needs as i went, as i mostly knew what i was doing now, and how to accomplish my lofty goals.

But 1.8.1 was a harpy disguised as a lover (I actual do enjoy it, already so many hours of personally fulfilling enjoyment). I just hate the fact so many core functions are changed without a single note as to what/how/why they now function or scrapes of information on how to use many of the cool new 'neat looking' functions. Add on top of the fast growing list of functionality i was depending on not being present any longer or mostly busted because it was not a feature GG needed to accomplish there own internal immediate goals( could also be lack of extensive QA over 'fringe and legacy' functions no longer deemed truly necessary. All total understandable and my comment is not a harsh judgment at GG for busting some eggs to make this new omelet).

What truly stabs and twists the blade deeper into my product loyalty, and confidence in a once easily comprehendable code base (Im a fricken game content artist who distaned the very thought of trying to learn true programing, who actually did learn,well everything i know about C'code and scripting from the simple TGE, along with many resources as a teacher, and the forums as a classroom.), is the fact the few questions i have actually ever needed to ask go ignored, not because no one else have a solution, but because the programmers who MADE the engine im asking about never seem to wish to spend the time on the more in depth problem, when they could easily skip it to tell someone else for the 100'th time that there specific problem is solved if they read the docs. (This is an example exaggeration)

As an observation in the last ~9 months i have seen a few very fascinating endlessly intriguing questions and presented problems go completely unanswered, only because the persons asking the 'hard' questions are usually from the few forum community members who consistently have taken the time to answer the plethora of simpler mondain problems from so very many 'newer' community members. Less then 20 members constantly spending hours of there time a day to be as endlessly helpful as possible, without expecting anything in return so very often not even a thank you as acknowledgment to there efforts.

#10 When i worked with 'big boy engine' on more 'professional' projects, when I presented a question on the forums not only did i often receive a flood of technical information, but most often it was directly from the engine developers themselves(who were very busy posting daily bug fix, optimizations to the code base, and implementing new features) and the one time i hit an unexpected bug, and sent an email at 3AM on a Sunday morning, I was shocked to get a rely at 8AM with the bug fix.

I might be spoiled from these halcyon days, but those core developers busted ass, full of respect for the people who depended on them. It was a symbiotic relationship. I often get the feeling GarageGames could care less for most of its loyal license holders. And even right this minuet i can scoot over the the other computer, open any random .c file from that big boy engine , and see every variable, every function, even the crazy math formulas are meticulously commented on. I dont need a degree in computer programing to know right away what things are doing where and why.

I did not expect to type this much and say any of what i finally did say. Im not at all ranting in a mad furry for not getting what i want when i want it, but expressing observations. And personally wondering if i expect to much from a company who got ~$50M from the IAC 'takeover'. I know we have all heard and seen this new "open communication with our community members who made us who we are!"; but if you think about it the open communication is all product hype. It do look like a great product. But i sorta miss the days when GG was a tinny start up, and it was often seen forum posts from the 'Top 4'. (I do clarify i was not permitted to posses any other game engine tech until after my active employment with the other 'big boy engine' and even now under strict NDA, not %100 sure if i can even talk about having a license with them, as it is not for development purposes commercial or otherwise)



Many hours of personally fulfilling enjoyment, Torque have been a great fun toy. Over the years costing far less then any gamebox machine thingy and offering many hours of 'fun' along with a feeling of great personal satisfaction. I am often completely amazed when i view some of the great work coming from fellow license holders, and silently applaud the skill and dedication i know it takes to get anything 'out in the wild'. And even with the seemingly judgmental statements above, i hope to be one of the first to own T3D.
Well if you read threw this far your either truly bored, one of the 20 gurus i spoke about above, or my keyboard blathering as i wait for my ray trace animations to render actually mean something.

#11 Jaimi, if you'll send fxRenderObject to me, I'll see if I can port it to 1.8.1 (seems that's all I've been doing lately anyway. :-D ) ((it's been a great learning experience))

MikeR at 3dcentral dot net

#12 Well said, Caylo.

I ported fxRenderObject to TSE and later TGEA, but I don't have the heart to do yet another port.

At one time I thought it was scheduled to be included with the Torque source since it was such a handy thing. I don't know what happened with that plan...

#13 fxRenderObject is the quintessential definition of a DOC also being a working example of how the shape rendering process fully work start to finish. Its not just a nice addition, its the cleanest most simple easy to understand overview of so many other very complex shape classes, who are all closely related, but subtly different. fxRenderObject is also the basic starting point to building ones very own custom object type.

Im amazed at the oversight that left this out. And a bit insulted that it may just be upto the customers who use the product to fix what was once deemed a necessary part from previous engine version, along with so many other slight yet unavoidable and very forgivable glitches, less they persistent to the point of constant hindrance to the true purpose of useing the product in the first place. Who should love the engine more the people who make it or the people who use it?

It just may be as i mention in above entry, am I spoiled by expecting a tad higher level of quality? Or is it the great majority of seemingly perfectly satisfied customers, who statistically many will hardly delve into the depth of the engine at all ergo never finding much to fault? In that case i must be expecting the impossible, and it is me who is without reasoning in such situation. I had never considered the possibility that i might need to treat the flagship Torque engine as one would a used car, with constant little tweaks and fixes as things are found lacking by nature of incomplete execution, and there is that nagging little feeling in the pit of the stomach forcing one to wonder if there were any true quality under the hood to start with, or just that real fancy paint job that is what sold the car in the first place. Perhaps a bit of polish, and put a flame stripe down the sides and i also can pass it off as 'sparkles'.

Most every time i have witness to someone acting out of touch emotionally from a lack of satisfaction in a Torque product, are so because somehow it is not fulfilling expectations. Of course a certain few of them are truly mad that it is actual work, and not as much fun as the dream they had.

I dont even know why I am monologuing my thoughts on the matter. It most probably be taken the wrong way by most people who bother to read it, and of course not at all by the ones who do not. Yet if it were not for dishearteningly finding yet another glaring fault i would be very busy focusing on implementing the custom game functions my many notebooks are packed so full of. Its not the difficulty of fixing one bug, but the very likely possibility of stumbling into the next one right after it. And it would be delightful if they were bugs introduced by my fumbling rather bugs left behind in seldom used corners. And is it fair at all to call them bugs, when it is just very unexpected behavior that at one time worked as it should in the previous engine version? Probably not bugs, little fluffy unhelpful code bunny's, at least that is funny.

#14 I'm not sure why you guys even want fxRenderObject anyway. Setting up a renderable object (to either render from a TSShapeInstance or render using a custom render delegate) is easier with GFX2 than its ever been before. TSStatic is fairly barebones as an example for rendering from a TSShapeInstance.

All you do is the standard stuff in prepRenderImage, then set up any transforms you want (with a GFXTransformSaver at the top of the scope) and call animate (if applicable) and then render on the TSShapeInstance (render merely submits a render instance). If you need some sort of custom rendering, you can do something like:

if (state->isObjectRendered(this))
   {
      ObjectRenderInst *ri = gRenderInstManager->allocInst<MeshRenderInst>();
      ri->mRenderDelegate.bind( this, &YourClass::_render );
      ri->state = state;
      ri->type = RenderPassManager::RIT_Mesh;
      gRenderInstManager->addInst( ri );
   }

// YourClass::_render() sets up your transforms and VB/IB (if applicable) and calls an appropriate draw function.

If you're rendering with a custom shader or whatnot, you'll also need to set up a stateblock and shader const buffer.

Personally, I think fxRenderObject isn't there simply because it isn't necessary. There are tons of examples of how to render from a mesh or render something custom, all over the engine.

#15 Ok Ross.
Here is the port I tried 5 months ago to get the fxRenderObject into TGEA 1.7.1.
I would appreciate it if someone could tell me what I didn't do correctly.
fxRenderObject.h

//-----------------------------------------------------------------------------
// Torque Game Engine
// 
// Written by Melvyn May, 9th September 2002.
//-----------------------------------------------------------------------------

#ifndef _FXRENDEROBJECT_H_
#define _FXRENDEROBJECT_H_

#ifndef _SCENEOBJECT_H_
#include "sim/sceneObject.h"
#endif

#ifndef _SCENEDATA_H_
#include "materials/sceneData.h"
#endif

#ifndef _MATINSTANCE_H_
#include "materials/matInstance.h"
#endif


//------------------------------------------------------------------------------
// Class: fxRenderObject
//------------------------------------------------------------------------------
class fxRenderObject : public SceneObject
{
private:
	typedef SceneObject		Parent;

protected:

	// Create and use these to specify custom events.
	//
	// NOTE:-	Using these allows you to group the changes into related
	//			events.  No need to change everything if something minor
	//			changes.  Only really important if you have *lots* of these
	//			objects at start-up or you send alot of changes whilst the
	//			game is in progress.
	//
	//			Use "setMaskBits(fxRenderObjectMask)" to signal.

	enum {	fxRenderObjectMask		= (1 << 0),
			fxRenderObjectAnother	= (1 << 1) };

	S32								mLastRenderTime;
	F32								mCurrentAngle;
   MatInstance*               mMaterial;
   //GFXTexHandle               mDetailTex;

	// Fields.
	F32								mQuadSize;
	F32								mQuadRotateSpeed;
   StringTableEntry				mMaterialName;
   //StringTableEntry           mDetailName;
   
   // Helper functions
   void render(SceneGraphData& sgd, MatInstance* mat);

   // Initialize the vertex buffer.  Returns number of
   // primitives in the buffer and the vertext buffer.
   // Don't destroy this buffer when you're done with it.
   virtual GFXVertexBuffer* initVertexBuffer(U32& numPrims);

public:
	fxRenderObject();
	~fxRenderObject();

	// SceneObject
void renderObject(SceneState* state, RenderInst *ri);
virtual bool prepRenderImage(SceneState*, const U32 stateKey, const U32 startZone,
								const bool modifyBaseZoneState = false);

	// SimObject      
	bool onAdd();
	void onRemove();
	void onEditorEnable();
	void onEditorDisable();
	void inspectPostApply();

	// NetObject
	U32 packUpdate(NetConnection *, U32, BitStream *);
	void unpackUpdate(NetConnection *, BitStream *);

	// ConObject.
	static void initPersistFields();

	// Declare Console Object.
	DECLARE_CONOBJECT(fxRenderObject);
};

#endif // _FXRENDEROBJECT_H_

#16 Oh I give up on trying to post the code.
Here is the link to it.
fxRenderObject

1000 words limit huh....ok.

The above code and link will compile for TGEA 1.7.1 but will not render correctly.
I already posted the rendering problems with this code here

#17 Well, I honestly don't remember anything about how 1.7.1 works. I haven't been looking at that version of the codebase for around 6 months or more now (actually longer I think). My post was referring to 1.8+.

#18 It is past my bed time and I probably shouldn't post while tired but...

fxRenderObject was created as a teaching tool and it is very useful as one.
fxRenderObject was the basis for a few other resources that would be great to have in TGEA 1.7.0 or newer.
fxSwarm
fxCloth
(fx)BasicShape

fxRenderObject should be updated and maintained by GG for all future releases of Torque.
It simply makes since.
The vehicle code is maintained as an example of how to do vehicles in TGE/A. Can you imagine having never seen Torque's vehicle code before and trying to create one from scratch?

The point is GG already maintains a number of example classes in there code as instructional devices.
Player , Vehicle , WheeledVehicle , HoverVehicle and FlyingVehicle classes to name a few.
They most likely won't do everything you would like them to do but you can build on to them to get your desired results.


fxRenderObject should be like that as well.

#19 @Jaimi McEntire - I somehow missed your post until now. Send it to me as well.

#20 @Jaimi,
thanks for the fxRenderObject, but its basicaly exactly what I got already, and the same problem, it compiles, I can place it in a scene, but it wont render, only shows the outlines in editor. maybe I'm just not using the material properly? dunno.

@Bill,
Jaimie's version is almost identical to yours.