PureBasic Forums - English

Posted: **Thu Mar 05, 2015 11:45 pm**

I have 14 cubes with textures.

If each cube has its own texture and it does not change. That these cubes can be made in 1000 and will have a steady 60fps.

However, as soon as we begin to draw in texture begins to slow.

At first I tried to draw a picture and draw a picture in texture and so for each cube. It was slow. For caused 14 * 2 startdrawing.

Then I poprobvat immediately draw in texture. It also slows for 14 start drawing.

Then I decided to cheat. I made one big texture on all cubes. 1024x1024 and each cube has allocated a piece of it. As a result, I have only 1 startdrawing. But still at 14 cubes FPS drops then 30FPS.

I think the problem is the speed of the procedure Plot.

Probably she did not immediately put an end to the video memory texture?
Is there a faster solution?

For each cube, I have the cycle 256x192 pixels. Optimize cycle nothing, because each frame is a new (something like a video).

Posted: **Fri Mar 06, 2015 4:42 am**

I do not know whether the importance of time between startdrawing and stopdrawing. I tried at first to draw all the data in memory, and from then on as quickly as possible with the help of copymemory copy in memory of each texture. However, this is almost no results.

Bottleneck PureBasic or Ogre?

Posted: **Fri Mar 06, 2015 9:59 am**

I don´t know exactly what you´re doing. Could you please give us a small snippet for testing surposes and better understanding of your Problem?

Posted: **Fri Mar 06, 2015 11:04 am**

I have videos in its own format. As a result of the decoding image is obtained 256x192 pixels. I pull on the cube texture. I need about 20 cubes and stable FPS 50-60.

So I have 20 textures and need to be updated 50-60 times per second.

Texture update loop:

Code: Select all

if StartDrawing( textureoutput( cubes()\texture ) )

   texture_mem = DrawingBuffer()
   scr2memory(*mem, texture_mem)

   stopdrawing()

endif

Procedure scr2memory ( *mem, mem)
  
 ; tm = ElapsedMilliseconds()
  
  For y = 0 To 191
    
    pixelLine = 32 * ((y & $C0) | ((y << 3) & $38) | ((y >> 3) & $07)) 
    attr      = 6144 + ((y & $F8) << 2)
     
    For x = 0 To 31
      
      chr_attr     =  PeekC(*mem + attr + x ) 
      chr_pixels   =  PeekC(*mem + pixelLine + x )
      
      Paper = (chr_attr >> 3) & $0F 
      ink   = (chr_attr & 7)  | ((chr_attr & 64) >> 3)
      
      bit = 128
      For z = 0 To 7
        
        If chr_pixels & bit
          
          ; Plot( xt + x<<3 + z, yt + y, color( ink&7 ))
          PokeL(mem + pix, color( ink&7 ))
          
        Else  
          
          PokeL(mem + pix, color( Paper&7 ))
          ; Plot( xt + x<<3 + z, yt + y, color( Paper&7 ))
          
        EndIf
        pix + 4
        bit >> 1
      Next z 
      
    Next x
 
  Next y
  
  ; Debug tm-ElapsedMilliseconds()
  
EndProcedure

Posted: **Fri Mar 06, 2015 11:15 am**

There are two issues here.

1. Plot puts an end to video mems or StartDrawing texture is copied to the main memory and at StopDrawing back?

2. Maybe the problem is the fact that the texture is updated and then it does not matter 1 pixel I put into it, or 256x192.
(in games, we usually deal with unchanged textures)

I know that there is a concept in OpenGL Batching.

http://gamedev.stackexchange.com/questi ... t-practice

Posted: **Fri Mar 06, 2015 3:33 pm**

i understand you want to put videos on 14 cubes at the same time,
i suggest to try the OpenCV example "pb_gl_cam_cube.pb"
http://purebasic.fr/english/viewtopic.p ... 55#p447832
it casts the web cam video lively to a one cube. don't know if it is possible with more cubes at once.
also try purebasic MP3D engine the example MP_MoviePlayer.pb it is also will cast an avi video to a rotating cube
also i suggest to try StaticGeometry.pb in the PB 3D examples, the hundreds of cubes in the scene are made from one cube so give it a texture from the video as you have done and see if this makes things speedier.
but 14 cubes with lively videos !! i think this is too much for a normal computer.

Posted: **Fri Mar 06, 2015 6:19 pm**

Updating materials is usually very fast. The start/stop drawing is where your slowdown is coming from and I'm not sure how you can speed that up.

Just to show you the swapping speed I created a little example. This code has 100 cubes all randomly swapping materials and I'm getting a steady 60 fps.

Code: Select all

;### WARNING!!
;### There are a lot of flashing cubes. Don't run this if you have epilepsy.

If InitEngine3D(#PB_Engine3D_DebugLog) = 0
  End
EndIf
If InitKeyboard() = 0
  End
EndIf
If InitSprite() = 0
  End
EndIf

Enumeration
  #Window
  #Camera
  #Light
  #Node
  #Texture1
  #Texture2
  #Texture3
  #Material1
  #Material2
  #Material3
  #PlaneMesh
  #Plane
  #CubeMesh
EndEnumeration

Global Dim EntityData.i(100, 2)
Global EntityTotal.i = 100

Declare TS_CreateCubes()
Declare TS_UpdateCubes()

If OpenWindow(#Window, 0, 0, 1024, 768, "Material Swapping", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  If OpenWindowedScreen(WindowID(#Window),0, 0, 1024, 768)

    Add3DArchive(#PB_Compiler_Home+"Examples\3D\Data\Textures", #PB_3DArchive_FileSystem)
    
    LoadTexture(#Texture1, "grass.jpg")
    LoadTexture(#Texture2, "clouds.jpg")
    LoadTexture(#Texture3, "dirt.jpg")
    
    CreateMaterial(#Material1, TextureID(#Texture1))
    CreateMaterial(#Material2, TextureID(#Texture2))
    CreateMaterial(#Material3, TextureID(#Texture3))
    
    CreatePlane(#PlaneMesh, 10, 10, 10, 10, 10, 10)
    CreateEntity(#Plane, MeshID(#PlaneMesh), MaterialID(#Material1), 0, 0, 0)
    
    CreateCube(#CubeMesh, 0.5)
    
    CreateLight(#Light, RGB(150, 150, 150), 0, 10, 12)

    CreateCamera(#Camera, 0, 0, 100, 100)
    MoveCamera(#Camera, 0, 5, 15, #PB_Absolute) 
    CameraLookAt(#Camera, 0, 1, 0)
    CameraBackColor(#Camera, RGB(30, 30, 30))
    
    CreateNode(#Node, 0, 0, 0)
    AttachNodeObject(#Node, CameraID(#Camera))
    
    TS_CreateCubes()

    Repeat
  
      Event = WindowEvent()
  
      ExamineKeyboard()

      TS_UpdateCubes()
      
      RotateNode(#Node, 0, 1, 0, #PB_Relative)
      
      RenderWorld()
      FlipBuffers()
 
    Until Event = #PB_Event_CloseWindow Or KeyboardReleased(#PB_Key_Escape)

  EndIf
EndIf
End

Procedure TS_CreateCubes()
  
  For CTR = 1 To EntityTotal
      
    x = Random(8, 0) - 4
    y = Random(5, 0)
    z = Random(8, 0) - 4
    m = Random(2, 1)
      
    If m = 1
      Material = #Material2
    Else 
      Material = #Material3
    EndIf
      
    Handle = CreateEntity(#PB_Any, MeshID(#CubeMesh), MaterialID(Material), x, y, z)
      
    EntityData(CTR, 1) = Handle
    EntityData(CTR, 2) = Material
      
  Next
  
EndProcedure

Procedure TS_UpdateCubes()
  
  For CTR = 1 To EntityTotal
    
    Handle = EntityData(CTR, 1)
    
    m = Random(2, 1)
      
    If m = 1
      Material = #Material2
    Else 
      Material = #Material3
    EndIf
    
    SetEntityMaterial(Handle, MaterialID(Material))
    
    EntityData(CTR, 2) = Material
    
  Next
    
EndProcedure

Posted: **Sun Mar 15, 2015 9:43 am**

applePi wrote:i understand you want to put videos on 14 cubes at the same time,
i suggest to try the OpenCV example "pb_gl_cam_cube.pb"
http://purebasic.fr/english/viewtopic.p ... 55#p447832
it casts the web cam video lively to a one cube. don't know if it is possible with more cubes at once.
also try purebasic MP3D engine the example MP_MoviePlayer.pb it is also will cast an avi video to a rotating cube
also i suggest to try StaticGeometry.pb in the PB 3D examples, the hundreds of cubes in the scene are made from one cube so give it a texture from the video as you have done and see if this makes things speedier.
but 14 cubes with lively videos !! i think this is too much for a normal computer.

http://www.youtube.com/watch?v=YVgXFY-NXTM

I think the point is not in the power of the computer or video card.
Watch the video. There a lot of textures that change in real time.

It is likely that the texture is actually one and it is a great example of 2048x2048 and her pieces are stretched to landfills.

I have tried to do so and it is slow.

Posted: **Sun Mar 15, 2015 9:46 am**

Samuel wrote:Updating materials is usually very fast. The start/stop drawing is where your slowdown is coming from and I'm not sure how you can speed that up.

Just to show you the swapping speed I created a little example. This code has 100 cubes all randomly swapping materials and I'm getting a steady 60 fps.

This is not surprising. you do not write in texture and upload them to video memory.

Posted: **Sun Mar 15, 2015 1:54 pm**

what you need is to create a dynamic texture:
http://www.ogre3d.org/tikiwiki/tiki-ind ... c+textures

I want to make a small example, but I don´t know how to get one Frame of a Video.

Posted: **Mon Mar 16, 2015 4:30 pm**

Bananenfreak wrote:what you need is to create a dynamic texture:
http://www.ogre3d.org/tikiwiki/tiki-ind ... c+textures

I want to make a small example, but I don´t know how to get one Frame of a Video.

Thank U!

It seems this is that that is necessary !!

You can not use the video, but just put random values in the texture.
Something like that.

Code: Select all

color = random (-1)
for y = 0 to 255
for x = 0 to 255

pokel (mem + pos, color)
color + 1
pos + 4

next x
next y

Posted: **Tue Mar 17, 2015 5:06 pm**

I believe the example Bananenfreak is talking about (all it does is update a pixel buffer) would still be slow even if you managed to get it working. It's not that different from how you were originally creating the textures.
Looking through examples of 3D perspective mapping I'd say that it's best to load the video frames and create every material for your perspective mapping beforehand. Then you can just swap them out one by one when you're displaying the mapping. Which would be very fast like the example I created above.

Posted: **Wed Mar 18, 2015 4:01 am**

Samuel wrote: Looking through examples of 3D perspective mapping I'd say that it's best to load the video frames and create every material for your perspective mapping beforehand. Then you can just swap them out one by one when you're displaying the mapping. Which would be very fast like the example I created above.

Unfortunately this is not possible. I use multiple sources of video mixing them in real time. Generative art.

There is really a different idea.
Video frame occupies 6912 bytes. And you can draw a texture as if it is not a texture array.
And then use the shader decompress data from this real-time texture.

It turns out that one texture 256x256x4 will have 37 frames at 6912 bytes.

PureBasic Forums - English

Draw to texture optimisation

Draw to texture optimisation

Re: Draw to texture optimisation

Re: Draw to texture optimisation

Re: Draw to texture optimisation

Re: Draw to texture optimisation

Re: Draw to texture optimisation

Re: Draw to texture optimisation

Re: Draw to texture optimisation

Re: Draw to texture optimisation

Re: Draw to texture optimisation

Re: Draw to texture optimisation

Re: Draw to texture optimisation

Re: Draw to texture optimisation