Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 26 Jul 2006
Offline Last Active Apr 12 2014 12:23 PM

#5065201 Animating ASSIMP models

Posted by Schrompf on 27 May 2013 - 04:36 AM

The Assimp documentation says that the data from the animation tracks replaces the node's local transformation. So yes, the animation data is "premultiplied" with the joint transformation. My suggestion is to not transform the animation data into local joint space.

#5058031 Strange textures when loading md5 model in AssImp

Posted by Schrompf on 30 April 2013 - 05:21 AM

Maybe the model creator mapped the texture to -1 .. 0 on one axis, and you activated texture coordinate clamping. The result would then look just like this.

#5053822 Multipass forward rendering?

Posted by Schrompf on 16 April 2013 - 07:19 AM

I'm not your debugger. Try it. 

#5053789 Multipass forward rendering?

Posted by Schrompf on 16 April 2013 - 05:30 AM

You accumulate by using Alpha Blending.

glEnable (GL_BLEND);
glBlendFunc (GL_ONE, GL_ONE);


From the top of my head, no guarantees given.

#5045212 What open source 3ds max to direct3d exporter are available?

Posted by Schrompf on 21 March 2013 - 05:40 AM

This is because the Direct3D scene file format does not support cameras. If you really need lights and cameras, I suggest looking into the Collada file format. FBX might also support this, but I'm not sure.

#5034479 Trigonometric Lookup Table: Float vs. Double

Posted by Schrompf on 20 February 2013 - 03:48 AM

I still wonder why you'd even bother to optimize this. 50 calls per frame? Incredible! Make that 500k calls and you'd need to start worrying. But even then the first thing you should do is to MEASURE. Stop guessing that something might be a problem, start measuring what actually consumes the most processing time. I'd wager that sin()/cos() won't even show up on the list.


Also: packing a double into an Java object to be able to pass it around by reference? Your math does really create thousands of small objects every frame, and most but not all of them are outscoped at the end of the frame. The garbage collector will love you.

#5033873 How to analyze models file

Posted by Schrompf on 18 February 2013 - 01:50 PM

You can do that, but it's going to be quite some work. I suggest to use a readymade library to load an intermediate file format instead, such as FBX or Assimp.

#5031861 forward rendering idea

Posted by Schrompf on 13 February 2013 - 10:19 AM

Try standard passing by constant registers first. Textures can store a lot more data than constant registers, but access to textures is pretty slow, and updating them is even slower. In contrast: reading from constant registers is "free" by nearly any measurement, and updating constant registers is quite cheap in my experience. And with 4096 x float4 constant registers you can still store a lot of lights.

#5027833 Anyone here a self-taught graphics programmer?

Posted by Schrompf on 01 February 2013 - 07:24 AM

Wow, Rob! That is an inspiring story! I, too, grew the most when I was thrown into an experienced team as a youngster. But let's start at the beginning:


It's 1985, East Germany is still strongly separated from West Germany, and it's still some sort of self-proclaimed democracy with nothing but the best in mind for its people. But some of its ideas were indeed genuinely well-minded - it mass-produced a little hardware board called the Z1013 - an 8bit processor with 16kb of RAM - with the intent to make its people comfortable with the technology and to grow a new generation of technic affine people for its economy. The state didn't last long enough to reap the fruits of this endeavour, but the idea was surprisingly smart and long-term. I was 6 years old at this time, my dad brought home one of these computers, and simply left his twin sons alone with it. We played on it, we watched our father code for it, and soon we picked up coding for ourselves. After all, getting new programs for that hardware was a matter of knowing the right people and copying their tapes, so we were stuck with the boxed software for a long time. 


There came a BASIC with it, and we did put it to use. In school we just started learning the first letters, at home we wrote the first simple programs. Without knowing a word of english, that also came along with the years. When BASIC wasn't interesting enough anymore, I even picked up machine code, writing my programs by putting hex bytes directly into memory and then losing it all at the next crash. I knew the meaning of the Carry and Overflow flags in my sleep, without knowing what the words mean.


Then we switched to a 4Mhz IBM compatible PC that the GDR cloned from some west technology, only to be overtaken by the turning of seasons and the fall of the eastern countries, where this precious technology suddenly turned into outdated trash. And we manipulated its character set to get some crude version of per-pixel graphics :-) But the times were new, everyone was excited to live in a new bright feature, only to learn that the humans on the other side of the fence were just humans, too, and with a surprisingly large amount of condescending assholes. There seems to be a constant percentage of these in any human society, but at times of the Cold War both sides at least tried to hide those, to give a better image to the opponent :-) Sorry for the derail.


Then we got an Amiga. Or better: our family bought one, but soon the only two people using it were my twin brother and me. We sure played at lot, but we also started coding with the Amiga BASIC that came with it. Side note: Amiga Basic was developed by Microsoft. We soon hit the limits of this programming language, and via some strange channels found AMOS, a basic dialect specifically for games. What an enlightment it was! We coded a lot of crude games for it, one of it we even tried to sell as Shareware, only to upload it for free after a few months and <10 units sold. Does that make me indie?


At some point we visited an exhibition for which our hardware dealer organized a trip, only to come back with StormC for ~300$. An C++ compiler and an IDE, so incredibly simple when compared to even the most basic text editor today. But to us it again marked the beginning of a new era. No more Copper List hacking in asm code fragments because that new shiny C language thing was so incredibly fast! It's a good thing that we didn't knew any coder forum back in 1997, or else there would be public witnesses for our method of learning. E.g. randomly trying both . and -> until everything clicked into place over the years. Then we also coded a successor to our shareware game, sporting a single player campaign and local multiplayer coop and deathmatch, which took us 4 years and finally reached the light in 2002. We sold an incredible amount of ~800 units, which was indeed a success when taking into account the devastating state of the Amiga at that time. Even today I still earn ~50$ per year from it :-)


And gradually we faded over to the PC. For example, somewhere in 1999 I started assembling my helper classes into a cross platform game framework that works both on Amiga and PC/Windows, and it still serves me well in 2013. That Amiga game we published got me an internship in a professional game development studio, where I arrived feeling like a veteran and left feeling like a rookie, but yet I grew tenfold smarter than before.  And even today, after two other jobs in software engineering and 10 years more, I'm still learning new things every day. I love my profession.


To stay at the thread topic: I wrote my first racing game using line shaped height maps in AMOS in 1995, I wrote a few software voxel renderers in 2001 or something, and I grew with the PC hardware from S3 Virge upto shader-based everything today. It's a beatiful place to be in today, as long as you have the time to bury yourself in front of your computer. Everything else comes freely and abundantly to you.


Yet I don't envy the young people today - the inspiration to take up coding of today comes in masses of shiny trailers with orchestral soundtrack made by dozens of highly qualified people. It must be hard to keep your faith against this. Back in my time I was excited by a few flat shaded polygons, and my only thought was "I can do that, too".

#5027158 HLSL (SM2/3): How do I transfer less-than-32 bit variables?

Posted by Schrompf on 30 January 2013 - 06:51 AM

I assume the context to be PC games. It might look different when you're running on a console.


On DX9 level hardware, UBYTE4 is indeed the best you can get. You can do some bit swizzling in the shader to combine 2x 4bit into one of these 4 bytes, but you can't specify anything less than 32bit. Thus this compression scheme is only useful if you can make other use of the remaining 3 bytes. 


A warning from experience: it won't help you much.


- It can save a lot of GPU memory, but this is only useful if you're handling literally millions of instances. If you're doing just a few tens of thousands of instances, I wouldn't waste my time on it. 

- It can save quite some memory bandwith, but I never found this to be the limiting factor. The best I got from compressing my instancing vertex structure from 56 bytes down to 20 bytes was 30% performance gain.

- It can save you transfer bandwith in case you're updating the instancing data every frame. In that case I'd say it's worth the hassle, but I'd wager you have other problems then.

- It won't help you in any other case. 


A few months ago I wrote a voxel renderer that splatted millions of textured quads. I first tried to use instancing, but it was slow as hell. 4 million quads resulted in ~15fps on my Geforce GTX 460. When trying to find the bottleneck I noticed that all counters of NVPerfHUD together only accounted for 30% of the frame time, and 70% went to "somewhere". Then I tried Visual NSight, which was buggy as fuck but at least could show me the real cause: the Input Assembler. Then I removed all instancing and stored four unique vertex structures per quad, with a total 80 bytes per quad, and I got to 55fps. For the very same geometry, and four times the GPU memory bandwith. Something is happening on those modern cards that I can't explain. An ATI GPU showed the same behaviour.

#5019034 Mesh file format?

Posted by Schrompf on 08 January 2013 - 07:58 AM

I do like Assimp, but I'm one of the founders so it's not surprising. Assimp works well for many people as far as I can tell from the feedback. And it can do a lot of processing for you to handle details you're not aware of at the beginning. Such are: calculating tangent space, triangulating complex shapes, splitting up meshes for vertex count or bone count, optimizing for GPUs post transform cache and so on.

To reiterate on what dougbinks said: it's not really suitable for everyday loading. For that, create a custom binary file format mirroring your engine's internal structures as closely as possible. Use Assimp only to load 3d files when they're new or you know they've changed, then inspect the asset and save it in your internal file format for quick loading times.

#4940432 flash runs c/c++

Posted by Schrompf on 15 May 2012 - 09:25 AM

An interpreter in Flash? Interesting idea, but I'd expect horrible performance from it. How many Ops per second do you expect it to achieve?

#4921730 Deferred Lighting via Compute Shaders

Posted by Schrompf on 13 March 2012 - 01:42 PM

As long as you're not dealing with shadows, enhancing your point light structures to cover spot lights would probably the better approach. It's just a few additional math ops, which GPUs are really good at. But as soon as shadows enter the arena, a separate pass would be better, I think. Point lights usually need a cube map or maybe a dual paraboloid maps, but it definitely differs from the plain and simple shadow handling of a spot light. You could reunite the both if you manage to put all shadow information on the same resource type, for example by unfolding your cubemaps manually, but I'm not sure if this gains you anything.

#4527873 Why 32bit float point texture cannot be filtered by hw?

Posted by Schrompf on 16 September 2009 - 09:39 PM

You'd have to slam that addition floating point modules to each texture unit... which are quite large for 32bit floating point math, in addition to the 16bit fp, 32bit integer units and stuff.

BTW, both the NVidia Geforce cards (starting with the 8000 series) and the ATI Radeon cards (starting with HD3000 series, I think) can filter and blend fp32 textures.

#4476056 PhysX - what does "cooking" mean?

Posted by Schrompf on 19 June 2009 - 01:41 AM

a) "Cooking" is a simple term for preprocessing your collision meshes. PhysX needs to convert your triangle data into its own structures, computing helper data along the way. This is necessary to allow collision tests against it, but you can write the resulting data to a file and load it pre-cooked in future runs.

b) To my knowledge, collision groups are for contact reports and filtering. That means that you can filter which sets of entities should collide with each other, and you can define on which of those groups you want to be notified when they collide.

Bye, Thomas