How things will work

Talk among developers, and propose and discuss general development planning/tackling/etc... feature in this forum.
Post Reply
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

How things will work

Post by strook »

Code: Select all

namespace GalaxyEngine
{
	class Star: public Ogre::MovableObject
	{
	public:
		Star(Ogre::uint32 subdivision, const Ogre::String &starColorMap);
		~Star();

		float getRadius() { return radius; }
		Ogre::uint32 getSubdivision() { return subdivision; }
		Ogre::MaterialPtr getMaterial() { return material; }
		Ogre::Technique *getBestTechnique() { return bestTechnique; }

		void _notifyCurrentCamera(Ogre::Camera *cam);
		void _updateRenderQueue(Ogre::RenderQueue *queue);
		bool isVisible();
		const Ogre::AxisAlignedBox &getBoundingBox(void) const { return bounds; }
		Ogre::Real getBoundingRadius(void) const { return radius; }
		const Ogre::String &getMovableType(void) const { static Ogre::String t = "Star"; return t; }
		void visitRenderables(Ogre::Renderable::Visitor* visitor, bool debugRenderables) {}

	private:
		void _generateNoiseMap();
		void _updateShader(Ogre::Camera *cam);
		Utility::Timer timer;

		Ogre::Real radius;
		Ogre::AxisAlignedBox bounds;

		Ogre::uint32 subdivision;
		Ogre::MaterialPtr material;
		Ogre::Technique *bestTechnique;	//This is recalculated every frame

		bool withinFarDistance;
		Ogre::Real minDistanceSquared;

		static bool noiseMapGenerated;
		
		//Animation data
		Ogre::ColourValue color;
		float animationPos;

		class StarRenderable: public Ogre::Renderable
		{
		public:
			StarRenderable(Star *star);
			~StarRenderable();

			void getRenderOperation(Ogre::RenderOperation& op);
			Ogre::Real getSquaredViewDepth(const Ogre::Camera* cam) const;
			const Ogre::LightList& getLights(void) const;

			Ogre::Technique *getTechnique() const { return star->getBestTechnique(); }
			const Ogre::MaterialPtr &getMaterial(void) const { return material; }
			void getWorldTransforms(Ogre::Matrix4* xform) const { *xform = star->_getParentNodeFullTransform(); }
			bool castsShadows(void) const { return false; }

		private:
			Star *star;

			//Rendering data for this chunk
			Ogre::VertexData vertexData;
			Ogre::IndexData indexData;
			Ogre::MaterialPtr material;
		};

		//Renderable instance
		StarRenderable *renderable;
	};

}
this is the header of an star displayed in my technical preview.

this shall only be a sample for the base of all renderable objects.

in fact there is one big problem: how shall i glue the output of two rendersystems together?

i came to the final conclusion:

1.:Renderable is the base class of all objects to be rendered in ogre.
2.: derive/convert all ogre objects explicitely from this class and enabling direct modifyable access to the vertex data and other rendering data.
3.:we do not use the ogre rendering engine! we use the vertex data to
create the render frame with the vs opengl functions.

so why do we use ogre then?
1.: we have a very good - easy to use - resource system.
2.: we could maybe in the future move to ogre completely.
3.: we can use the easy ogre programming lib and the vs lib for maximum flexibility.

so what is the bum?
1.:it should be slower, cause ogre holds all of its data on the graphics card.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
log0

Re: How things will work

Post by log0 »

I am curious, what is keeping you from using Ogre renderer?

Keeping data in GPU memory is actually the fastest way afaik.
Gungnir
Mercenary
Mercenary
Posts: 98
Joined: Thu May 06, 2010 5:57 am

Re: How things will work

Post by Gungnir »

log0 wrote: Keeping data in GPU memory is actually the fastest way afaik.
It would be at least as fast, if not faster; if you run out of VRAM, it should switch to normal RAM.

I agree with log0, it seems like we should go ahead and use ogre's renderer.
~Gungnir
segfault wrote:if I was actually in space I'd totally be throwing on autopilot and relaxing in the back during the trip, sipping space wine and listening (rlaan?) jazz.
Rig: i5 2500k @ 5ghz, 2x OCZ Agility 3 120gb SSD boot drives, AMD Radeon HD 7950 @ 1100/1575 (Catalyst 12.1 Linux and 12.3 Windows), dual-boot Fedora 16 KDE and Windows 7 Pro
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: How things will work

Post by strook »

I repeat - there is No usuable way to render ogre contents and OpenGL contents together.
The reason is: the renderer needs all objects to render a frame which is swapped into VRAM .
I am not shure if ogre holds all of it's data in VRAM, I 've heard it.

Normally you create your scene in ram and copy it into VRAM. Thus displaying it.
There is a new way the last years -to use shaders that work in real on the graphics card.
Ogre has many simple ways to use them.

But in fact we can load it all in with ogre and convert it into a vegastrike OpenGL shader context.

I am not right familiar to100% with the vs shader system, but there are low level routines to set arbitrary values for shaders and easy to use load in functions.

So we could create an ogre render 3d object derived from a base class like it is mentioned above. Only using the load in functions for the shaders and the vertex data.
I do not know if there is a simple way to convert the whole material (the textures)
Lightning is just a vector and a color if needed.

Of course , you can modify inside the ogre engine the ogre data prior reading it out for displaying it with OpenGL. Or you read it out and create an OpenGL unit from it.

The jumping point is: there is only an experimental way to show ogre contents in sdl, then we had to loose glut support, and We can only render one frame

This means we can only render the ogre frame and then the OpenGL or vice versatile, but this isn't a solution.

This would mean we had to rewrite the whole programm to use ogre. Better the ogre render system.

This is in fact not needed
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Re: How things will work

Post by loki1950 »

Strook I think that I should bring this thread to the attention of chuck_starchaser who has been salivated at Ogre's shaders for some time :wink: And as he is very much graphics go to guy :)

Enjoy the Chioce :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
log0

Re: How things will work

Post by log0 »

I see. Why would someone want to use bare OpenGL if he has OGRE doing it for him. What is missing, shader and texture setup? I wish I had the time to look into the code. :?
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: How things will work

Post by strook »

Ok in short it is the holy cow of compatibility, log0 :wink:

We have to use it. Well, if you want to use a cg shader or another shader that isn't in vs implemented, you get into problems.

Also I'll have a look onto the conversion of ogre materials, but it shouldn't be the thing.
The rest should work well since we use quasi the geometry data from ogre. Maybe a resizement should be done. The shaders should work well(in fact I'll run into problems using some ogre extensions or so, cause they use cg shaders).

Loki: Well if chuck has some hints for me, let them roll on :wink:
I did take many looks on the vs OpenGL vertex lists.

Actually, I'm again fighting with linker errors. My libs are for 64 bit but I compile for 32.
I disabled 2 cores and used Xcode 3 so I can compile now...
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
log0

Re: How things will work

Post by log0 »

"OGRE requires a base OpenGL version of 1.2.1" and vegastrike is using GLSL shaders. Maybe there is a way to skip the materials and load the shaders/textures directly. I have to admit I have no idea about OGRE API.

From OGRE forum: "You can assign shaders to objects using the material system"
log0

Re: How things will work

Post by log0 »

One would have to write the materials for the object/shader combinations right? Like:

Code: Select all

vertex_program pssm_vsm_caster_vp glsl
{
    source pssm_vsm_caster_vp.glsl

    default_params
    {
        param_named_auto wvMat worldview_matrix
    }
}

fragment_program pssm_vsm_caster_fp glsl
{
    source pssm_vsm_caster_fp.glsl

    default_params
    {
        param_named_auto depthRange scene_depth_range
    }
}
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: How things will work

Post by strook »

Ya, ya I know, I meant ogre is supporting multiple shader language formats.
Gsgl is one of them which uses vs.
But one important ogre extension uses the cg language.

Also I barely don't know wether I can use the ogre extensions, cause they want to write in an ogre window, I think I'll put much work in it here to convert it to vs OpenGL.

What i'm talking about is hydrax, caelum, and other extensions.

But I have to put anyway work in them to get things running with them
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: How things will work

Post by strook »

Yep :) these are already being used be vs
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
log0

Re: How things will work

Post by log0 »

I think I would stick with the ogre window. Is there code in your fork to create one? I'd like to try to load/draw something simple like a vessel + glsl shader.
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: How things will work

Post by strook »

download vegaogre revision 184.
i'm just throwing out the cegui support. many other things to throw out.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
log0

Re: How things will work

Post by log0 »

Won't build on fc15 x86_64, gcc 4.6.0:

Code: Select all

/src/cmd/unit_const_cache.h:45: undefined reference to `std::tr1::hash<boost::container::basic_string<char, ....
Error log: http://pastebin.com/YwcwVyFt
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: How things will work

Post by strook »

It doesn't seem that you have boost installed or configured it right in cmake-gui .
Also, we have vegaogre not tested successfully on Linux 64 bit.
It may work or not.
If you want to make efforts that it runs on Linux 64 bit, plz notify me that we can meet in te vs irc channel.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
log0

Re: How things will work

Post by log0 »

Nope boost is fine.
#endif //if HAVE_TR1_UNORDERED_MAP ...
has to be moved before class hash< vs_string > definition in src/gnuhash.h.

Now I have to fix the remaining undefined references in the ai, aggfire and such.

What compiler are you using gcc4.2?
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: How things will work

Post by strook »

This will most likely bring you to a runtime error or worse.

Since you have gcc 4.6

HAVE_TR1_UNORDERED_MAP

Won't be undefined as you see in the start of the file.

Unless it isn't defined at all, this location in your code won't compiled at all.

Look in your config.h wether it is defined.

I use gcc 4.2.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: How things will work

Post by strook »

as last step to complete ogre integration i'll use the an ogre dummy render window.
this is needed cause ogre isn't initialized correctly and crashes without it.

so i'll use the ogre rendertotexture mechanism to generate as render target thus creating the planet textures.

all needed is a bump map shader to create hills and mountains in vegastrike.

i think there is already one.

also caelum can't be used anymore, but hydrax and newton dynamics party, i think.

the big advantage is we can use all types of shaders ogre supports to generate the textures.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
Post Reply